Go原生支持增量构建，但需确保缓存未被绕过或禁用；go install比go build更积极写入缓存，能更好复用依赖编译产物，且缓存键包含源码哈希、CGO_ENABLED、GOOS/GOARCH等，任一变化即失效。
Go 原生就支持增量构建，不需要额外工具或 Makefile——但前提是缓存没被你无意中绕过或禁用。
go build 和 go install 的缓存行为差异
很多人以为 go build 和 go install 只是输出位置不同，其实它们对缓存的“写入意愿”完全不同：
-
go build会读缓存、用缓存，但默认不把编译结果（尤其是依赖包的.a归档）写入缓存索引；反复调用时可能因路径/时间戳等微小差异跳过缓存复用 -
go install强制将每个包的编译产物持久化进$GOCACHE，并严格按源码哈希+环境变量（CGO_ENABLED、GOOS、GOARCH等）生成缓存键，后续构建只要输入一致就秒出 - 如果你项目有多个
main包（比如cmd/app1、cmd/app2），用go install ./一次性安装全部，比逐个go build -o bin/app1 cmd/app1更稳、更快
哪些操作会让缓存失效（比文档写的更常见）
缓存键是内容哈希，但“内容”范围比想象中广。以下改动都会导致整个包重编，哪怕只改了一行注释：
-
-ldflags值变化：比如-ldflags="-X main.version=1.0.0"→"-X main.version=1.0.1"，链接输入变了，缓存失效 -
CGO_ENABLED在 0 和 1 之间切换：cgo 对象文件和纯 Go 编译产物完全隔离，不能混用 - Go 版本升级后首次构建：缓存 key 含
go version，旧缓存自动作废 - CI 中未复用
$GOCACHE目录：每次 job 都是空缓存，等于裸跑 - 手动执行
go clean -cache后没验证是否真有必要——多数时候只是因为某次构建慢，就清缓存，反而让后续几次都变慢
如何确认缓存正在工作
别猜，直接看证据：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 运行
go build -x main.go，观察输出里是否出现类似cd /Users/me/Library/Caches/go-build/xx/yy的路径访问（说明在读缓存） - 第一次构建耗时 3s，立刻再跑一次
go build main.go—— 如果输出为空且耗时0.1s，基本就是命中了 - 检查缓存大小：
du -sh $(go env GOCACHE)，全新项目下如果是0B或几 MB，说明缓存压根没积累起来 - 临时禁用对比：
GOCACHE=off go build main.go，再和正常模式比耗时，差距越大，说明原来缓存越有效
CI/CD 中必须做的三件事
本地快不代表流水线快，CI 环境容易把缓存变成摆设：
- 显式设置
GOCACHE路径并持久化：GitHub Actions 用actions/cache缓存${{ env.HOME }}/Library/Caches/go-build（macOS）或${{ env.HOME }}/.cache/go-build（Linux） - 固定影响缓存 key 的环境变量：在 CI 脚本开头统一声明
CGO_ENABLED=0、GOOS=linux、GOARCH=amd64，避免分支间参数漂移 - 用
go install替代go build输出二进制：配合GOBIN=$(pwd)/bin，既避免污染全局$GOPATH/bin，又确保缓存被充分写入和复用
缓存不是魔法，它只忠实地记住你做过什么；真正让它持续生效的，是你构建命令的一致性、环境变量的稳定性，以及对 go install 这个被低估的命令的重新认识。
