$GOCACHE不能跨机器同步，因其缓存的编译中间产物与CPU指令集、操作系统ABI及Go工具链版本强绑定；而$GOPATH/pkg/mod可共享，但需Go版本和GOPROXY等配置一致。
不同主机上 go build 行为不一致，八成是 $GOCACHE 搞的鬼，不是 $GOPATH/pkg/mod 的问题。
为什么 $GOCACHE 不能跨机器同步
Go 的构建缓存（$GOCACHE）存的是编译中间产物（.a 文件、对象文件），它和 CPU 指令集、操作系统 ABI、甚至当前 Go 工具链版本强绑定。同一份源码，在 macOS 上生成的缓存拿到 Linux 上直接用，go build 会报 invalid cache object 或静默跳过——根本不会提醒你，只默默变慢。
-
$GOCACHE默认路径：Linux 是$HOME/.cache/go-build，macOS 是$HOME/Library/Caches/go-build，Windows 是%LocalAppData%\go-build - CI 环境中每次 clean 构建是常态，
$GOCACHE本就不该持久化 - 别用
rsync或cp -r同步整个$GOCACHE目录，毫无意义且可能干扰本地构建
哪些缓存可以/应该跨主机共享
真正影响依赖一致性的，是模块下载缓存 $GOPATH/pkg/mod，它存的是源码快照（带校验和），平台无关，可共享——但需满足两个前提：
- 所有主机使用相同 Go 版本（至少主次版本一致，如都是
1.23.x） -
go env GOPROXY配置一致，避免一台走代理、一台直连导致拉到不同 commit - 私有模块需统一配置
GOPRIVATE和GONOSUMDB，否则校验失败会中断解析
如果真要共享模块缓存，建议用 NFS 或 CI 缓存服务挂载 $GOPATH/pkg/mod，而非手动拷贝。
立即学习“go语言免费学习笔记（深入）”；
go clean -cache -modcache 什么时候必须一起跑
当你在新机器上 clone 项目后首次 go build 出现奇怪行为（比如 panic 在 stdlib 里、或 go mod tidy 无输出却没拉依赖），大概率是旧缓存残留作祟。此时单独清 -modcache 不够，因为构建缓存里可能还存着基于旧模块版本生成的中间文件。
- 执行
go clean -cache -modcache -i：一并清理构建缓存、模块缓存、已安装命令 - 再运行
go mod download显式触发依赖下载，比go mod tidy更可靠（后者可能跳过已声明但未使用的依赖） - 验证缓存状态：
go env GOCACHE和go env GOMODCACHE输出是否合理，路径里别出现/tmp或权限异常目录
CI/CD 中如何安全提速而不踩坑
GitHub Actions、GitLab CI 等平台推荐用 actions/cache 或 cache step 缓存 $GOCACHE，但 key 必须包含：
-
go-version（如1.23.5） -
os（如ubuntu-22.04） -
go-env-hash（可选，对GOPROXY、GOPRIVATE等关键变量做 hash）
不要缓存 $GOPATH/pkg/mod —— 它体积大、更新频繁，且 go mod download 本身已经足够快；反而容易因 key 冲突导致不同分支拉错版本。
真正麻烦的从来不是“怎么缓存”，而是“缓存里混进了谁的旧东西”。遇到问题先看 go env 输出是否干净，再动手删，比盲目重装 Go 有效得多。
