Go构建慢主因是缓存失效、cgo启用、Dockerfile顺序错误及工具链不当；优化go.mod单独COPY、CGO_ENABLED=0、启用BuildKit可降50%以上耗时。
Go 项目构建慢，八成不是代码问题，而是缓存没生效、cgo 拦路、Dockerfile 写法拖累，或工具链选错。只要改掉这几个关键点，50% 以上的构建耗时能直接砍掉。
为什么 go build 越来越慢？先查缓存是否真在用
Go 自 1.10 起默认启用编译缓存，但很多团队其实没真正用上——比如误设 GOCACHE=off，或 CI 中每次清空缓存再构建。
- 运行
go env GOCACHE确认路径存在且可写；常见错误是挂载了只读 volume 或权限不足 - 避免在 CI 脚本里写
go clean -cache，除非明确需要排除缓存干扰的调试场景 - 检查缓存命中率：构建后看输出中是否有
cached字样；没有则说明包被强制重编（比如修改了go:generate注释或 cgo 标志） - 跨平台构建时，
GOCACHE默认按GOOS/GOARCH分区，不用额外配置，但别手动覆盖GOBIN导致路径混乱
CGO_ENABLED=0 不只是为 Alpine，更是为编译速度
含 cgo 的包会触发 C 编译器调用、生成临时文件、链接动态库，单个包编译时间可能比纯 Go 包慢 3–5 倍。即使你不用 C 代码，只要依赖里有 net 或 os/user 等包，在非 Linux 环境下就可能隐式启用 cgo。
- 生产构建一律加
CGO_ENABLED=0，确保静态链接，同时规避 libc 兼容问题 - 若必须用 cgo（如 SQLite、OpenSSL），把相关逻辑拆到独立包（如
internal/cgo），并用构建标签隔离：// +build cgo - 本地开发时可保留 cgo（方便调试），但 CI 和镜像构建阶段必须关闭
- 注意：禁用 cgo 后
net.LookupIP等函数会回退到纯 Go 实现，行为一致，无需改代码
Docker 构建慢？go.mod 必须单独 COPY，且用 BuildKit
传统 Dockerfile 把源码 COPY . . 放在 go mod download 之前，导致每次改一行代码都重拉全部依赖——这是最常被忽略的性能黑洞。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 正确顺序：
COPY go.mod go.sum .→RUN go mod download→COPY . .→RUN go build - 务必启用 BuildKit：
DOCKER_BUILDKIT=1 docker build .，它支持并发 layer 构建和更精确的缓存失效判断 - 如果项目用了私有模块，确保
go env GOPROXY已设为可用地址（如https://goproxy.io,direct），否则go mod download会卡在超时重试 - 不要在 Dockerfile 里
RUN go mod vendor，vendor 目录会放大镜像体积，且现代 Go 已不推荐
该换构建工具了吗？Makefile 和 bazel 的真实分水岭
不是“要不要用新工具”，而是“你的项目是否已跨过增量构建收益阈值”。小项目硬上 Bazel 反而拖慢迭代，大项目死守 Makefile 会把 8 秒的增量构建变成 40 秒。
- 当项目稳定在 30+ 包、日均变更涉及 5 个以上子模块时，
bazel的缓存命中率（实测 >90%）开始碾压make（基本 0%） -
Makefile适合快速验证、CI 回滚脚本、或仅需build/test两三个目标的简单服务 - 若已有
go.work或多模块结构，bazel的 WORKSPACE 配置复杂度会显著降低 - 注意：Bazel 首次构建比 Makefile 慢 10–20%，别拿首次时间做决策，重点看第二次及以后
真正卡住构建效率的，往往不是某行代码写得不够快，而是构建上下文里混进了不该有的东西：一个未 ignore 的 .git 目录、一次多余的 go clean、Dockerfile 里多写的 RUN apt-get update……这些细节不盯住，再好的架构也白搭。
