go clean -modcache 删除的是 $GOMODCACHE（默认为 $GOPATH/pkg/mod）下的全部模块缓存内容，包括各版本模块的解压源码目录、.mod、.info 和 .zip 文件，但不触碰 go.mod、go.sum、vendor/ 或 $GOCACHE。
go clean -modcache 到底删了什么
它清空的是 $GOMODCACHE（默认为 $GOPATH/pkg/mod）下的全部内容，包括：
• 每个模块版本的解压源码目录（如 golang.org/x/net@v0.25.0/）
• 对应的 .mod、.info、.zip 文件（存于 $GOMODCACHE/cache/download）
• 但不会碰 go.mod、go.sum、vendor/ 或构建缓存 $GOCACHE
缓存“命中”不等于“可用”
Go 构建时不是看目录是否存在，而是严格走三步校验：
• 查 go.sum 中该模块版本的 checksum 记录
• 读缓存中对应版本的 .info 文件
• 两者 mismatch → 直接报 checksum mismatch 并拒绝使用
这意味着：
• 手动改过 $GOPATH/pkg/mod 里的源码？下次 go build 就会失败
• go mod verify 能复现这个检查过程，CI 中建议固定执行
• go.sum 必须提交进 Git，否则不同人本地缓存可能各自校验通过、但内容实际不一致
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
为什么 go mod tidy 有时不下载依赖
常见假象是“缓存坏了”，实际多为逻辑误判：
• go mod tidy 只处理 go.mod 中声明的依赖，不会主动拉取未 require 的模块
• 切换分支后 go.mod 版本变了，旧缓存还在——只是没被用上，不是失效
• 私有模块代理配置漏了 direct（如 GOPROXY=https://goproxy.cn 未加 ,direct），请求卡在 fallback 阶段
• 磁盘满导致 go mod download 写入中断，缓存里留下残缺 .zip 和不匹配的 .info，后续校验必败
立即学习“go语言免费学习笔记（深入）”；
清理前最该留下的两样东西
全量清缓存不可逆，但没必要裸奔重建：
• 保留当前项目的 go.mod 和 go.sum —— 它们才是依赖树的唯一事实来源
• 运行 go list -m -json all > deps.json，生成含 Version、Replace、Indirect 的结构化快照，比手动记日志可靠得多
• 若用私有模块，确认 go env GOPRIVATE 已设（如 git.internal.company.com/*），否则清理后 go get 可能跳过校验拉错版本
