判断模块缓存是否陈旧需结合go list -m all输出与$GOPATH/pkg/mod/cache/download实际目录比对：未出现在依赖树中且非私有已下线模块的，即为陈旧缓存；精准清理应提取活跃模块列表后反向过滤删除，而非直接go clean -modcache全量清除。
怎么判断哪些模块缓存是“陈旧”的
模块缓存是否陈旧，不能只看时间戳，得结合使用状态和项目依赖树来判断。Go 不会自动标记或清理“过期”缓存，go mod tidy 只改 go.mod，不碰 $GOPATH/pkg/mod 里的文件。
真正有效的判断方式是：运行 go list -m all，它输出当前构建解析出的所有模块（含间接依赖）；再对比 ls $GOPATH/pkg/mod/cache/download 下实际存在的域名/路径目录——那些没出现在 list -m all 结果里、又不是你私有仓库（且已下线）的，基本就是陈旧缓存。
- 公共模块（如
golang.org/x/...、github.com/sirupsen/logrus）如果版本号在go.mod里已被降级或移除，对应缓存就该清 - 私有模块（如
git.internal.company.com/legacy/project）若已从代码中彻底删除 import，且go mod graph里查不到引用链，那它的 zip 和解压目录就是陈旧的 -
go clean -modcache是全量删除，无法区分新旧；想精准清理，就得靠比对结果手动删
如何安全地只删陈旧模块缓存，不伤当前依赖
直接 rm -rf $GOPATH/pkg/mod 太粗暴，尤其在团队协作或 CI 中会造成重复下载带宽浪费。更稳妥的做法是提取当前活跃模块列表，再反向过滤缓存目录。
执行以下三步：
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 在项目根目录运行：
go list -m -json all | jq -r '.Path' | sort -u > active_modules.txt（需装jq） - 提取所有缓存域名：
find $GOPATH/pkg/mod/cache/download -mindepth 2 -maxdepth 2 -type d -exec basename {} \; | sort -u > cached_domains.txt - 对比并删掉未被使用的私有域名缓存：
comm -13
注意：这个方法对公共模块效果有限（因为同一域名下多个版本共存），但能精准清除已下线的私有模块缓存，避免代理污染或 checksum mismatch。
为什么 go mod tidy 不会删磁盘上的旧模块文件
go mod tidy 的职责仅限于同步 go.mod 和 go.sum —— 它调整的是“声明”，不是“物理存储”。即使你 tidy 后 go.mod 里只剩 github.com/go-sql-driver/mysql v1.14.0，$GOPATH/pkg/mod 里仍可能躺着 v1.10.0、v1.12.0 等多个版本的源码和 zip 包。
- 这些残留文件不会影响构建，Go 默认用
go.mod指定的版本 - 但它们会持续占用磁盘空间，尤其在频繁试错、切分支、换代理后容易膨胀到 10GB+
- 如果你发现
du -sh $GOPATH/pkg/mod远大于go list -m all | wc -l× 5MB（平均模块大小），大概率就是陈旧缓存堆积
清理后要验证什么，避免“删了却没生效”
删完缓存不代表问题消失，尤其当 IDE 或后台进程还在 hold 文件句柄时，磁盘空间不会立刻释放，旧缓存也可能被悄悄重建。
- 执行
lsof +D $GOPATH/pkg/mod 2>/dev/null | wc -l，输出非 0 就说明 VS Code、GoLand 或某个go build进程仍在读取缓存目录，得先关掉它们 - 跑一次
go build -v ./... 2>&1 | grep "Fetching"，确认拉取地址是你期望的代理（比如https://goproxy.cn），而不是直连 GitHub - 检查
go env GOSUMDB是否仍是默认值sum.golang.org；如果之前设为off或私有 sumdb，清理后校验可能失败，需重置
真正的陈旧缓存清理，不是一次命令的事，而是把 go list -m all 当作事实来源、把 go mod graph 当作依赖拓扑图、把 lsof 当作句柄守门人——三者缺一不可。
