go mod tidy 卡住是因多进程竞争模块缓存锁，解决方案是隔离 gopath 或串行化执行；-mod=readonly 和 -mod=vendor 可避免加锁，但需确保依赖一致。
go mod tidy 为什么会卡住或报错 locking $GOPATH/pkg/mod/cache/download
并发执行 go mod tidy 时，多个进程会同时尝试写入模块缓存（$GOPATH/pkg/mod/cache），而 Go 的模块下载器内部用文件锁保护这个目录。一旦某个进程没释放锁（比如被 Ctrl+C 中断、panic 或磁盘 I/O 卡顿），后续的 go mod tidy 就会阻塞在 “locking …” 提示上，甚至超时失败。
这不是 bug，是设计使然：Go 模块缓存不是线程安全的，更不是多进程安全的。官方明确不保证并发 go mod 命令的可靠性。
- 常见错误现象：
go: downloading example.com/lib v1.2.0后长时间无响应；终端卡在locking $GOPATH/pkg/mod/cache/download/... - 典型场景：CI 中并行跑多个构建 job（如不同 GOOS/GOARCH）、Makefile 里用
&启动多个go mod tidy - 别指望靠
GOPROXY=off或GO111MODULE=on绕过——锁依然存在，只是换了个路径（~/.cache/go-build不参与此锁，但模块缓存锁照旧）
如何安全地在 CI 或脚本中并发调用 go mod tidy
核心原则：让每个并发任务拥有独立的模块缓存和 GOPATH，彻底隔离锁竞争。
- 用
GOPATH环境变量为每个任务指定唯一路径，例如：GOPATH=$(mktemp -d) go mod tidy - 配合
GOCACHE隔离构建缓存（虽不影响模块锁，但避免编译干扰）：GOCACHE=$(mktemp -d) GOPATH=$(mktemp -d) go mod tidy - 如果必须复用缓存（比如节省 CI 时间），改用串行化：用
flock或简单 shell 锁文件控制，例如：flock /tmp/go-mod-tidy.lock -c "go mod tidy" - 注意
go mod tidy -v会暴露更多锁等待细节，调试时建议加上
go mod tidy 的 -mod=readonly 和 -mod=vendor 差异对锁的影响
这两个参数不改变锁行为本身，但会影响是否触发下载，从而间接决定是否进入加锁路径。
立即学习“go语言免费学习笔记（深入）”；
-
go mod tidy -mod=readonly：只校验依赖完整性，不下载缺失模块 → 不会触碰pkg/mod/cache下载锁 → 安全并发 -
go mod tidy -mod=vendor：只检查 vendor 目录，完全跳过模块缓存操作 → 也不加锁 → 可并发 - 但只要没 vendor 或
vendor/modules.txt过期，它仍可能 fallback 到模块模式 → 锁风险回归 - 所以真想并发又省事，优先用
-mod=readonly+ 确保go.sum和go.mod一致（CI 前先跑一次干净的go mod tidy）
为什么 go clean -modcache 不解决并发卡死问题
go clean -modcache 清的是缓存内容，不是锁文件。Go 的锁是运行时创建的临时文件（如 $GOMODCACHE/.lock），进程退出异常时可能残留，但 go clean 不清理它。
- 真正有效的清理方式是手动删锁文件：
rm -f $GOPATH/pkg/mod/cache/.lock（注意路径中的cache，不是cache/download） - 更稳妥的做法是避免依赖人工清理：在 CI 容器启动时就设好隔离的
GOPATH，或用go env -w GOPATH=$(mktemp -d)动态覆盖 - 某些旧版 Go（go mod，没有绕过办法
模块缓存锁是 Go 构建链里少数不透明且不可配置的环节。它不报错、不超时、不提示重试，只沉默等待——最容易被当成网络慢或代理问题排查半天。盯住 locking 这个词，比查 proxy 日志快十倍。
