并发构建时模块缓存被重复写入的根源是Go模块缓存未实现跨进程原子写入保护，导致多个go build进程同时下载解压同一模块文件引发损坏；应精准清理对应模块的.zip、.info等残留文件，而非清空整个缓存。
并发构建时模块缓存被重复写入的根源
Go 的 go build 在并发执行（如 Makefile 里并行跑多个 go build -o bin/cmd1 ./cmd/cmd1 和 go build -o bin/cmd2 ./cmd/cmd2）时，pkg/mod/cache/download 下同一模块的 .zip 和 .info 文件可能被多个进程同时尝试下载或解压，导致文件损坏、校验失败或残留临时文件（如 .zip.tmp）。这不是 bug，而是 Go 模块缓存未做跨进程原子写入保护的结果。
清理重复/损坏的模块缓存文件
直接删整个缓存太粗暴，且会拖慢后续构建。优先定位并清理真正出问题的部分：
- 检查错误日志里出现的模块路径，例如
invalid version: unknown revision abc123或checksum mismatch for github.com/some/lib，提取域名和模块名（如github.com/some/lib） - 进入缓存目录：
ls $GOPATH/pkg/mod/cache/download/，找到对应域名子目录（如github.com/some/） - 删掉该目录下所有以模块名开头的
.zip、.info、.ziphash和残留的.tmp文件 —— 不要删整个域名目录，只清具体模块 - 运行
go mod download -v验证是否能干净拉取：它会跳过已存在的完整包，只重下缺失或损坏的
避免并发构建时再产生重复缓存
根本解法不是事后清理，而是让并发构建共享一致的缓存状态：
- 确保所有并发命令都使用相同的
GOPROXY（如https://proxy.golang.org,direct），禁用本地代理或私有 Nexus 未同步时的竞态 - 在 CI 脚本开头统一加
go mod download，等所有依赖就位后再并行go build—— 这样所有子任务都读缓存，不写缓存 - 若必须边下边构，设置环境变量
GOCACHE=$HOME/.cache/go-build（可选，不影响 mod cache）+GOENV=$HOME/.config/go/env，避免不同用户或容器覆盖彼此的go env配置 - 不要在
go build命令里混用-mod=readonly和-mod=vendor切换，这会导致模块解析逻辑反复重载，加剧缓存争用
为什么 go clean -modcache 不是并发问题的首选方案
它确实能清掉所有缓存，但副作用明显：
立即学习“go语言免费学习笔记（深入）”；
- 下次所有并发构建都会各自重下全部依赖，带宽和时间成本翻倍
- 如果某次构建中途失败，
go clean -modcache会把其他成功构建已缓存的干净包也一并删掉 - 私有模块（
go env GOPRIVATE设置的）在清理后可能因网络策略或认证失效而拉不到，比公共模块更难恢复
真正要盯住的，是 pkg/mod/cache/download 下那些带 .tmp 后缀或大小为 0 的文件 —— 它们才是并发冲突留下的真实痕迹，而不是整个缓存目录。
