go mod tidy无输出但未下载依赖，首要解决方法是执行go clean -modcache清理缓存，再确认go.mod模块路径正确、goproxy和goprivate配置无误，最后运行go mod download验证网络与权限。
go mod tidy 无输出但依赖不下载？先清缓存再重试
这是项目重命名、模块路径变更或缓存损坏后最典型的症状。Go 工具链不是“卡住”，而是发现缓存里找不到匹配新模块路径的依赖条目，于是静默跳过下载——它没报错，但也没干活。
-
go clean -modcache是唯一可靠的第一步，不要跳过。它会删除$GOMODCACHE下所有已缓存的模块（包括校验和、zip 包和解压源码），强制后续命令从头拉取 - 执行前确认当前目录下有有效的
go.mod，且其中module行声明的路径与实际导入路径一致（比如module github.com/yourname/new-project） - 清理后立即运行
go mod download，比go mod tidy更早暴露网络或权限问题；如果它成功，再跑go mod tidy
GOPROXY 配置错误导致连接超时或 403
国内环境不配代理，go get 或 go mod tidy 基本等于碰运气。默认的 https://proxy.golang.org 在多数网络下不可达，且不支持 fallback。
- 推荐配置（持久生效）：
go env -w GOPROXY=https://goproxy.cn,direct。逗号分隔表示“先试 goproxy.cn，失败再直连”，direct必须写在末尾，否则私有库会 403 - 验证是否生效：
go env GOPROXY输出应与设置一致；若为空或仍是默认值，说明 shell 配置未加载（macOS/Linux 检查~/.zshrc或~/.bash_profile） - 避免常见错误：代理地址不能以
http://开头；多个代理之间不能有空格；direct不是字符串字面量，是 Go 内置关键字，必须小写
私有仓库 403 或 “module lookup failed”？GOPRIVATE 没设对
即使配了国内代理，只要项目引用了 GitHub 私有库、GitLab 自建实例或内网 Git，Go 仍会把请求发给代理，结果就是 403 或找不到模块。
- 必须显式声明哪些域名走直连：
go env -w GOPRIVATE="git.internal.company.com,github.com/my-org/*"。通配符*只支持后缀匹配，不支持中间通配 - 如果同时用
GONOPROXY（旧版变量），优先用GOPRIVATE，后者覆盖范围更广且是当前标准 - 设置后，
go list -m all中对应私有模块的路径应显示为=>后跟本地路径或原始 URL，而非代理地址
校验失败卡住？GOSUMDB 和 GONOSUMDB 的取舍
当 go mod download 卡在某个模块、反复重试或报 checksum mismatch，大概率是 sum.golang.org 校验服务不可达，而 Go 默认不允许跳过。
- 开发阶段最稳妥方案：
go env -w GOSUMDB=off。关闭全局校验，避免因网络问题阻塞流程 - 若需保留校验但换源，可设
GOSUMDB=sum.golang.org+local（需自建），但国内极少用；更现实的是配合GOPRIVATE对私有模块禁用校验：go env -w GONOSUMDB="git.internal.company.com" - 注意：
GOSUMDB=off和GONOSUMDB不能共存，后者只对指定域名生效，前者全局关闭
真正容易被忽略的不是某一行命令，而是缓存、代理、私有域、校验这四者之间的耦合关系——改一个变量，可能触发另一个环节的连锁反应。每次修复前，先用 go env | grep -E 'GOPROXY|GOPRIVATE|GOSUMDB' 看一眼当前真实配置，比凭记忆操作可靠得多。
