go clean -modcache 仅清理 $gomodcache 中的模块源码、.zip 包和校验文件，不触碰 go.mod、go.sum 和 vendor/，且不会立即触发重新下载，需后续构建命令（如 go build）才会拉取，故执行后 go list -m all 无变化属正常现象。
Go 没有“临时模块目录”这个概念——你真正想清理的，是 $GOMODCACHE（模块缓存目录），它不是临时的，但常被误认为可随意删；删错路径或时机，会导致构建失败、校验不一致甚至拉错私有模块。
为什么 go clean -modcache 有时像没起作用
它只清 $GOMODCACHE 下的模块源码、.zip 包和校验文件，但不会动：go.mod、go.sum、vendor/，也不会触发重新下载——直到下次 go build 或 go list 需要时才拉。所以执行完命令后立刻 go list -m all 看不到变化，是正常现象。
常见误判场景：
- 执行前
GO111MODULE=off→ 命令静默跳过，什么也不删 - 设置了
GOPROXY=off且没配GOPRIVATE→ 清理后go get可能因跳过校验而拉错版本 - CI 环境里用的是旧版 Go（如 1.16 以下）→
-modcache参数不支持，得用rm -rf $(go env GOMODCACHE) - 目录被挂载为只读（如某些容器环境）→
go clean -modcache报permission denied却不提示失败
go mod tidy 和 go clean -modcache 到底谁该先跑
go mod tidy 管的是 go.mod 的声明逻辑，go clean -modcache 管的是磁盘上已下载的物理文件。二者不互斥，但顺序影响结果：
- 想精准瘦身：先
go mod tidy，再go clean -modcache—— 这样缓存里只剩当前项目真用到的模块 - 怀疑缓存损坏（如
checksum mismatch）：直接go clean -modcache，再go mod tidy重建依赖树 - 刚切了 Git 分支且
go.mod有变更：必须先go mod tidy同步声明，再清理缓存，否则go build可能因找不到模块报错 - 用了
replace指向本地路径：清理缓存不影响replace行为，但若本地路径被删，go build会立刻失败，不是缓存问题
删模块缓存前最该检查的三件事
不是所有 $GOMODCACHE 下的内容都该一刀切：
- 确认
go env GOMODCACHE输出路径是否真实存在且可写 —— 某些 CI 镜像里该变量为空，go clean -modcache实际清的是$GOPATH/pkg/mod - 检查
go env GOPROXY和GOPRIVATE：如果拉的是私有仓库，清理后首次go build会暴露认证问题（比如 token 过期、域名解析失败），别等发布前才发现 - 运行
go list -m -json all | jq -r '.Path' | sort -u > deps.txt备份当前实际依赖列表，万一清理后拉包超时或失败，能快速还原关键模块（例如手动go get github.com/org/repo@v1.2.3）
真正的难点不在“怎么删”，而在“删完之后谁来保证下次构建不崩”——缓存是加速器，不是保险丝；删它之前，得先让 go.mod 和网络环境都站得住脚。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
