go构建缓存默认生效，但易被-a、go.mod变更、goproxy未配、ci重置gocache等操作绕过；确认方式：二次build耗时
Go 的构建缓存默认就生效，不需要额外开启；但你很可能正 unknowingly 绕过它——比如用了 -a、改了 go.mod、没配 GOPROXY，或者在 CI 里每次重置 $GOCACHE 目录。
怎么确认缓存是否真在工作
别猜，直接看证据。两次连续执行 go build，如果第二次几乎不输出、耗时低于 0.3 秒，基本就是命中了。
更可靠的方式是加 -x 观察底层路径：
- 首次构建会看到类似
cd /tmp/go-build123这样的临时目录 - 二次构建若出现
cd $GOCACHE/v2/8a/8a7f...，说明正在读缓存 - 用
du -sh $(go env GOCACHE)查大小：空目录或只有几 MB，说明缓存基本没积累起来
哪些操作会让缓存静默失效
缓存 key 是按输入内容哈希生成的，任何微小变动都可能让整个包重建。常见但容易被忽略的点：
-
-ldflags="-X main.version=$(git rev-parse HEAD)"：每次 commit 都变，链接阶段输入不同 → 缓存失效 -
CGO_ENABLED=0和CGO_ENABLED=1的缓存完全隔离，混用等于两个世界 - CI 中未挂载持久化
$GOCACHE，每次 job 都是全新缓存目录 - 本地改了
.go文件但没git add，又用了go run—— 它内部调用go build，但临时可执行文件名含时间戳，掩盖了缓存真实状态 - 升级 Go 版本后第一次构建必然全量重编，因为缓存 key 包含
go version
真正能稳住缓存的实操动作
不是“清缓存重试”，而是让缓存持续可用：
- CI 配置中显式设置
GOCACHE=/tmp/go-cache，并挂载为持久卷（GitHub Actions 推荐缓存${{ env.HOME }}/Library/Caches/go-build或${{ env.HOME }}/.cache/go-build） - 开发时彻底去掉
-a、-n、-work这类干扰缓存逻辑的 flag - 对 CLI 工具，用
go install替代go build：它同样复用缓存，且输出路径固定，下次调用更快定位 - 交叉编译时统一环境变量，例如
GOOS=linux CGO_ENABLED=0 go build和GOOS=darwin CGO_ENABLED=1 go build的缓存互不共享，别混着跑
CGO 场景下缓存特别难稳住
CGO 不只是多了一层 C 编译，它把整个缓存敏感度拉高了一个量级：
-
CGO_CFLAGS和CGO_LDFLAGS变了，哪怕只加了个空格，缓存 key 就不同 - C 头文件路径（
-I./include）或库路径（-L./lib）写成相对路径，不同工作目录下哈希值不同 → 建议用绝对路径或通过$(pwd)显式展开 - C 源码未变但
gcc版本变了（如 macOS 升级 Xcode），缓存也会失效，因为 CGO 编译器版本参与哈希计算 - 想长期稳定，建议把 C 代码提前编译成静态库（
libmy.a），然后只在 Go 侧用CGO_LDFLAGS="-L. -lmy"链接——这样 Go 代码修改不会触发 C 重编
缓存不是魔法，它是靠严格一致的输入换来的确定性。最容易被忽略的，其实是环境变量和构建路径的隐式变化——它们不会报错，只会悄悄让你的缓存形同虚设。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
