Go构建瓶颈不在编译器本身，而在go list扫描、sum.golang.org校验、go:generate重跑及CGO_ENABLED=1调用gcc/clang；多阶段Docker构建须严格分离编译与运行阶段，并交叉编译时显式设CGO_ENABLED=0确保静态链接。
go build -x 显示的耗时环节才是真瓶颈
别急着优化代码或加 -a 参数，先运行 go build -x ./cmd/app 看输出。真正拖慢你的几乎从来不是 Go 编译器本身，而是：
– go list 扫描整个模块树（尤其含 replace 或本地路径时）
– 每次校验 sum.golang.org（国内直连常 TLS 握手卡 5–10 秒）
– go:generate 无差别重跑（改一行 handler 却触发 protobuf 全量生成）
– CGO_ENABLED=1 启用后调用 gcc/clang，完全脱离 Go 原生快车道
Docker 多阶段构建必须分清“编译阶段”和“运行阶段”
用 golang:1.26-alpine 做第一阶段只干三件事：拷贝 go.mod + go.sum → go mod download → go build -o /app/bin/myapp；第二阶段必须换 gcr.io/distroless/static:nonroot 这类无 shell 镜像，只 COPY --from=0 /app/bin/myapp /myapp。漏掉任意一步，镜像体积就多出 300MB+，且攻击面扩大。
GOOS/GOARCH 交叉编译前务必禁用 cgo
交叉编译时 cgo 默认关闭，但如果你在 main.go 里写了 // #include <stdio.h></stdio.h> 或用了 net 包的 DNS 解析逻辑，不显式设 CGO_ENABLED=0 就会静默失败或 fallback 到慢速纯 Go 实现。
– 正确写法：CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o myapp-linux-arm64
– 错误写法：只设 GOOS/GOARCH，没关 cgo，导致 DNS 解析变慢、二进制含 libc 依赖
– 验证方式：file myapp-linux-arm64 输出不含 “dynamically linked”，才算成功静态链接
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
本地开发别信 go build -i，它早该淘汰了
go build -i 是 Go 1.12 之前的遗留参数，现在不仅无效，还可能干扰缓存命中。
– 真正起作用的是内置编译缓存（GOCACHE），默认开启，路径由 go env GOCACHE 查看
– go clean -cache 是最常见误操作，相当于把整个缓存库删掉，下次构建从零开始
– 大型项目中，一个包修改会触发其所有下游依赖重编——这时与其等全量 rebuild，不如直接 go build ./cmd/xxx 只编译目标命令
立即学习“go语言免费学习笔记（深入）”；
