go模块缓存体积膨胀主因是$gopath/pkg/mod默认保留所有下载版本的.zip包及解压文件，频繁切换分支、试用不同go.mod版本或执行go get -u会堆积大量未被引用的旧版本和冗余校验文件，且私有模块的git commit hash伪版本号也被视为独立模块存储。
为什么 go mod download 会悄悄增大缓存体积
Go 模块缓存（$GOPATH/pkg/mod）默认会保留所有下载版本的原始压缩包（.zip）和解压后模块树，哪怕你只用其中某个子目录。频繁切换分支、试用不同 go.mod 版本或执行 go get -u 后，缓存中会堆积大量未被引用的旧版本和冗余校验文件。
go clean -modcache 不是万能解法
直接清空整个模块缓存虽能释放空间，但代价是下次 go build 或 go test 必须重下全部依赖，尤其在 CI 环境中会导致构建时间陡增。更糟的是，它无法区分“当前项目真正需要”和“历史残留”的模块。
- 缓存体积膨胀主因不是单个大包，而是大量小版本（如
v1.2.3、v1.2.4-0.20250101123456-abcdef123456）共存 -
go mod download默认拉取go.sum中所有条目，包括间接依赖的完整版本链 - 私有模块若使用 git commit hash 作为伪版本号，每个 hash 都会被视为独立模块存入缓存
用 go mod download -json + go mod graph 定向清理
真正精简缓存的关键，是只保留当前 go.mod 解析出的**精确依赖图**所涉及的模块版本，跳过所有未被实际引用的“幽灵版本”。
- 先生成当前项目最小依赖集：
go mod graph | awk '{print $1}' | sort -u | xargs go mod download -json 2>/dev/null | jq -r '.Path + "@" + .Version' | sort -u > used.mods - 再对比缓存目录，找出未被使用的模块路径：
find $GOPATH/pkg/mod/cache/download -name "*.info" -exec dirname {} \; | xargs -I{} basename {} | sed 's/\.info$//' | sort -u | comm -23 - - 对输出的冗余模块，手动
rm -rf $GOPATH/pkg/mod/cache/download/<path>@<version></version></path>
注意：go mod download -json 输出含校验信息，比单纯解析 go.sum 更可靠；comm -23 要求两个输入已排序，顺序错会导致误删。
构建时绕过冗余模块缓存的硬核参数
如果不想碰缓存目录本身，可在构建命令中强制 Go 忽略某些模块路径，让缓存“逻辑上变小”：
- 用
GOEXPERIMENT=nogowork（Go 1.21+）禁用go.work文件影响，避免多模块工作区意外引入额外依赖 - 设置
GOPROXY=direct临时关闭代理，防止因代理缓存污染本地pkg/mod（尤其当代理返回了非标准版本时） - 构建前加
go mod tidy -v，它会打印被移除的 require 行——这些模块大概率已不在缓存活跃路径中，可后续针对性清理 - CI 构建脚本中，在
go build前插入go mod download $(go list -f '{{join .Deps "\n"}}' . | grep -v '^golang.org/' | sort -u)，只预热真正参与编译的依赖
最易被忽略的一点：模块缓存体积问题往往在 go test -race 或 go run 后突然爆发，因为这些命令会触发额外的隐式依赖解析，而它们的缓存路径和 go build 并不完全隔离。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
