根本原因是go build默认反复编译所有依赖且不复用中间产物，尤其在含大量internal包、//go:embed或cgo时触发全量重编；解决方案包括使用-mod=readonly、-trimpath及合理配置$gocache。
为什么 go build 在大型项目里越来越卡
根本原因不是 Go 本身慢，而是默认行为会反复编译所有依赖（包括标准库），且不复用中间产物。尤其当项目含几十个 internal 包、大量 //go:embed 或 cgo 时，每次 go build 实际在做全量重编译。
- Go 1.19+ 默认启用
GOPROXY=direct且关闭模块缓存验证时，go mod download可能被重复触发 -
go build -a这种强制重编译标志仍在某些 CI 脚本里残留，它会让标准库也重新编译一遍 - 频繁修改
go.mod（比如加删replace）会导致$GOCACHE失效，缓存命中率暴跌
go build 必加的三个参数
不用改代码、不换构建工具，加这三个参数就能立竿见影：
-
-mod=readonly：禁止自动修改go.mod，避免因误触go mod tidy导致缓存失效 -
-trimpath：去掉编译路径信息，让相同源码在不同机器/路径下生成一致的输出哈希，提升$GOCACHE复用率 -
-buildmode=archive（仅调试时）：跳过链接阶段，只生成.a归档文件，适合验证包编译是否通过，比完整构建快 3–5 倍
日常构建推荐组合：go build -mod=readonly -trimpath -o myapp ./cmd/myapp
缓存目录 $GOCACHE 不生效的常见原因
$GOCACHE 默认指向 $HOME/Library/Caches/go-build（macOS）或 $HOME/.cache/go-build（Linux），但它很容易“静默失效”：
- 磁盘空间不足（
go env GOCACHE查路径后，用du -sh $(go env GOCACHE)看大小） - CI 环境未持久化该目录（Docker 构建中没挂载
/root/.cache/go-build） - 用了
go run调试——它默认绕过$GOCACHE，改用临时目录；必须显式写成go build -o /tmp/a && /tmp/a才走缓存 - 交叉编译（如
GOOS=linux go build）会另开缓存子目录，但若混用CGO_ENABLED=0和CGO_ENABLED=1，缓存完全不共享
模块级构建优化：用 go list 精准编译变更包
大型项目里，90% 的日常修改只影响少数几个包。与其 go build ./... 全量扫，不如只编译真正变过的：
- 查哪些包变了：
git status --porcelain | grep '\.go$' | xargs dirname | sort -u | xargs go list -f '{{.ImportPath}}' - 只构建这些包及其直接依赖：
go build $(上述命令) - 注意：
go list输出含vendor路径时需过滤，否则可能漏掉主模块外的变更
这个方法在 monorepo 场景下特别有效，但要求团队统一用 go mod vendor 或明确模块边界，否则容易漏依赖。
最麻烦的其实是 cgo 和嵌入资源——它们让缓存失效毫无征兆，改一行 //go:embed 就得重编整个包。这类地方建议单独抽成小模块，和业务逻辑解耦。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
