go build一改就卡住几秒，根本原因不在编译器本身，而是go list扫描、sum.golang.org校验超时、go:generate重复执行、cgo调用及误用-a/-i等非编译环节耗时。
go build 为什么一改就卡住几秒？先看真实瓶颈在哪
不是 Go 编译器慢，而是你每次 go build 都在等网络、扫描或生成——真正耗时的环节根本不在 compile 阶段。执行 go build -x 就能暴露问题：
• go list 扫描整个模块树（尤其含 replace 或本地路径时）
• 连接 sum.golang.org 校验哈希（国内直连常 TLS 握手卡 5–10 秒）
• 每次都触发 go:generate（哪怕只改了 main.go）
• CGO_ENABLED=1 启用后调用 gcc/clang，彻底脱离 Go 原生快车道
• 误用 -a 或 -i（Go 1.12+ 已废弃，强制全量重编，绕过缓存）
必须立刻检查的三个环境变量
GOPROXY、GOSUMDB、GOCACHE 是编译速度的底层开关，错一个就拖慢整条链路：
• GOPROXY 必须设为国内镜像，例如：go env -w GOPROXY=https://goproxy.cn,direct
• GOSUMDB 在内网可信环境可关掉：go env -w GOSUMDB=off；若需校验，改用 sum.golang.google.cn
• GOCACHE 默认开启，但容易“静默失效”：用 go env GOCACHE 查路径，再运行 du -sh $(go env GOCACHE) 看是否为空或磁盘满；CI 中未挂载该目录也会导致缓存完全不复用
日常构建命令要加这三参数
不用改代码、不换工具，加这三个参数就能立竿见影：
• -mod=readonly：禁止自动修改 go.mod，避免 go mod tidy 触发导致缓存失效
• -trimpath：去掉编译路径信息，让相同源码在不同机器/路径下生成一致哈希，大幅提升 $GOCACHE 复用率
• （调试时）-buildmode=archive：跳过链接阶段，只生成 .a 归档，比完整构建快 3–5 倍
推荐组合：go build -mod=readonly -trimpath -o myapp ./cmd/myapp
别让热重载工具偷偷破坏你的缓存
像 air 或 reflex 这类工具默认行为反而会拖慢开发：
• 它们监听所有 .go 文件变更，却无差别触发 go generate + go build，哪怕你只改了一行注释
• 多个 binary 并行构建时通常串行执行，浪费 CPU 和缓存复用机会
• .air.toml 配置稍错（比如忽略 go.mod 变更），就会导致缓存失效
更可控的做法是：
• 用 make 或 just 控制粒度，例如：make dev 执行 go build -trimpath -o bin/app ./cmd/app
• 用 fswatch（macOS）或 inotifywait（Linux）只监听 .go 文件，触发你定义好的 clean build
• 真要用 air，禁用其自动生成逻辑，只让它监听并执行 make dev
最易被忽略的点是：go run 默认绕过 $GOCACHE，它用临时目录编译；想走缓存就得显式写成 go build -o /tmp/a && /tmp/a。还有交叉编译时，CGO_ENABLED=0 和 CGO_ENABLED=1 的缓存完全不共享，别混着用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
