Go build默认单线程执行，不跑满CPU是因串行依赖解析设计，避免资源争抢、保障可重现性与低内存峰值；需用-p参数显式启用包级并行编译，与GOMAXPROCS无关。
Go 默认不并行编译，go build 是单线程执行的；想真正利用多核加速编译，必须显式启用并行构建，且需理解它和运行时 goroutine 调度是两套独立机制。
为什么 go build 默认不跑满 CPU？
Go 的构建工具链（go build）底层使用的是串行依赖解析 + 单 worker 编译流程。即使你有 16 核 CPU，go build 默认也只用 1 个逻辑处理器做编译工作，其余核心空闲——这不是 bug，而是设计选择：避免资源争抢、保证构建可重现性、降低内存峰值。
- 可通过
go env GOMAXPROCS查看当前 Go 运行时默认最大 OS 线程数，但这对go build无效 -
go build不受GOMAXPROCS控制，它有自己的并发开关 - 真正的并行编译能力从 Go 1.9 开始引入，但需手动开启
如何启用并行编译？用 -p 参数控制 worker 数量
并行编译靠 -p（parallel）参数控制并发编译 worker 数，不是靠环境变量或 runtime 设置。
-
go build -p 4：最多同时编译 4 个包（含依赖），适合中等规模项目 -
go build -p $(nproc)（Linux/macOS）：设为 CPU 逻辑核心数，常见做法 -
go build -p 1：强制退化为串行，用于调试或规避链接冲突 - 值过大（如
-p 100）反而可能因调度开销和内存竞争导致总耗时上升
注意：-p 控制的是「包级并行」，不是函数或 goroutine 级别——它决定有多少个独立的 package 编译任务能同时进行，每个任务内部仍是单线程编译。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
并行编译和 runtime 的 GOMAXPROCS 有什么关系？
完全无关。这是最容易混淆的点。
-
GOMAXPROCS只影响 Go 程序**运行时**的 goroutine 调度器能使用的 OS 线程上限，对go build这个命令本身无任何作用 -
go build是一个独立的 Go 程序（由 Go 源码写成），它启动时会按自己逻辑设置内部并发数，不读取你项目里的GOMAXPROCS设置 - 你在代码里调用
runtime.GOMAXPROCS(8)，只会影响你go run main.go启动后的程序，不影响go build过程
换句话说：编译时的并行，靠 -p；运行时的并行，靠 GOMAXPROCS 和 goroutine 数量；两者不能互相替代，也不能互相感知。
实际效果差异：小项目几乎无感，大模块项目提升明显
并行编译收益取决于项目结构，不是单纯看代码行数。
- 单包项目（如只有
main.go）：-p 参数无效，始终串行 - 多 module / 多 vendor 包项目（如含
github.com/gorilla/mux,golang.org/x/net）：-p 提升显著，尤其首次构建时 - 使用
go mod vendor后，-p 效果更稳定（避免网络拉包阻塞） - CI 场景建议固定
-p值（如-p 4），避免不同机器核心数导致构建时间波动
实测参考（i7-8700K, 6c12t）：含 37 个依赖包的微服务项目，go build 耗时 3.8s，go build -p 8 耗时 1.9s —— 接近线性加速，但前提是依赖图足够宽、无强串行瓶颈。
真正容易被忽略的是：并行编译不会改变生成的二进制行为，也不影响运行时性能；它只是缩短了「从敲下回车到得到可执行文件」这段时间。如果你在本地开发中没感受到速度变化，先检查项目是否真有可并行的包依赖结构，而不是盲目调高 -p 值。
