总体情况
在 Ubuntu 上执行 go build 进行打包时，资源占用通常表现为：CPU 会接近满载以进行并行编译，内存占用与项目规模、依赖数量、构建并发度相关，常见为数百 MB 到 1–2 GB；同时可能出现较大的虚拟内存（VSZ）占用，但这并不等同于真实物理内存消耗。例如，一个简单程序运行时的 VSZ 可达约379 MB，而 RSS 仅约5.11 MB，说明虚拟内存指标容易“看起来很高”。在资源受限环境下，可通过增加Swap缓解编译期 OOM。
常见影响因素
- 项目体量与依赖数量：依赖越多、文件越多，解析与类型检查开销越大，内存与 CPU 占用越高。
- 并行度：Go 编译器默认会并行编译包，并发度越高，CPU 越满，瞬时内存也会随之上升；可通过环境变量或构建参数控制并发度。
- 构建缓存：启用 **Go 构建缓存（GOCACHE）**可显著减少重复编译时间；使用 sccache/distcc 等缓存/分布式编译工具也能降低本地资源压力。
- 链接阶段：最终链接（尤其是 CGO 启用时）可能较为吃内存；静态编译或交叉编译阶段的内存峰值也可能升高。
降低资源占用的做法
- 控制并发与缓存：将并发度设置为合理值（如接近 CPU 核心数），并确保 GOCACHE 有效；必要时使用 sccache/distcc 分担编译负载。
- 优化编译参数：发布时常用 -ldflags “-s -w” 去除符号与调试信息，既减小二进制体积，也能一定程度降低链接阶段压力。
- 减少动态依赖：在不需要 C 库时设置 CGO_ENABLED=0 进行纯静态编译，可避免外部链接带来的额外开销与不确定性。
- 内存不足时的兜底：临时增加 Swap 空间，避免因瞬时峰值导致 OOM。
Docker 场景的额外说明
若是在 Docker 中打包，镜像层与基础镜像选择会显著影响“占用”观感：使用 golang:latest 作为构建基础会产生较大的中间镜像（示例约872 MB）；采用多阶段构建并将最终二进制复制到 ubuntu 或更小的基础镜像，可得到约80.5 MB的运行时镜像；进一步使用 scratch 基础镜像，可将镜像压到**30 MB+**量级。
