go mod tidy无反应时，应先执行go clean -modcache清除本地模块缓存，再运行go mod download重新下载依赖，最后执行go mod tidy同步依赖树，该流程可解决缓存损坏或项目重命名导致的路径不匹配问题。
go mod tidy 无反应？先清缓存再重试
遇到 go mod tidy 卡住、不报错也不下载依赖，大概率是模块缓存损坏或路径变更导致的失效。这不是网络问题，而是 Go 工具链在缓存中找不到与新 go.mod 模块路径匹配的已下载数据。
- 执行
go clean -modcache彻底清除所有本地模块缓存（路径通常为$GOPATH/pkg/mod） - 再运行
go mod download，强制从远程重新拉取go.mod中声明的所有依赖 - 最后
go mod tidy才能正常识别并同步依赖树 - 该流程对项目重命名（如从
github.com/a/old改为github.com/a/new）、切换 GOPROXY 或升级 Go 版本后尤其必要
GOPROXY 配置不当会导致重试失败
Go 的模块下载本身不带自动重试逻辑——它只尝试一次代理，失败就 fallback 到 direct，但 fallback 行为受 GOPROXY 字符串顺序严格控制。错误配置会让工具链“以为重试了”，实际根本没走备用路径。
- 正确写法：
export GOPROXY=https://goproxy.cn,direct（逗号分隔，direct必须显式写出） - 错误写法：
GOPROXY=https://goproxy.cn（缺direct→ 失败后直接报错，不 fallback） - 若私有模块被代理拦截（如企业内网），需把私有域名加进
GONOSUMDB，否则校验失败会中断整个下载流程 - 临时验证代理是否生效：运行
go env GOPROXY和go list -m all，观察是否卡在某个模块
replace 不是重试，是绕过缓存的定向替换
replace 在 go.mod 中的作用不是触发重试，而是让构建时跳过远程解析，直接使用本地路径或指定 commit。它常被误用于“修复下载失败”，但本质是开发阶段的临时覆盖手段。
- 语法示例：
replace github.com/some/lib => /home/user/src/lib或replace github.com/some/lib => github.com/fork/lib v1.2.3 - 仅对当前 module 生效，不会影响其他依赖对该库的引用（除非用
//indirect标记） - 提交前必须移除本地路径
replace，否则 CI 构建必然失败；Git 提交时建议用.gitignore过滤掉replace行 - 它不解决缓存污染，只规避下载环节——真正的问题（如 checksum mismatch）仍需通过
go clean -modcache清理
模块校验失败时，GOSUMDB=off 是临时解法而非重试开关
GOSUMDB=off 并非启用重试，而是关闭模块校验（即跳过 sum.golang.org 签名验证）。它在调试或离线环境有用，但会带来安全风险，且不能修复已损坏的缓存条目。
- 临时禁用：
GOSUMDB=off go mod download（仅本次命令生效） - 长期禁用会丢失对恶意包的防护能力，生产环境严禁设置为永久值
- 更安全的做法是：先
go clean -modcache，再确保GOPROXY可达，最后让 Go 自动重新计算并缓存校验和 - 若持续出现
checksum mismatch，优先检查是否有人手动修改了 vendor 下的文件，或 Git 仓库中存在换行符不一致等隐性变更
direct 必须显式写在 GOPROXY 末尾，以及 replace 提交前未清理——这两个点在线上构建失败中占比极高。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
