go clean -modcache 后依赖不重新下载，是因为 go 仅在模块树不满足声明时才触发下载，而非清空缓存即重拉；需检查 goproxy 是否生效、避免代理绕过、保留 $gopath/pkg/mod/cache/download 目录以复用下载物，并精准清理旧路径缓存。
go clean -modcache 之后依赖不重新下载？先检查 GOPROXY 是否生效
执行 go clean -modcache 后，go mod tidy 或 go build 却没触发任何下载，大概率不是缓存没清干净，而是代理配置失效或被绕过。Go 默认会跳过下载，只要它认为“当前模块树已满足声明”，哪怕本地缓存全空。
- 运行
go env GOPROXY，确认输出不是off或空；国内环境常见错误是设成了https://proxy.golang.org但实际无法访问 - 若用
goproxy.cn，确保末尾带,direct：正确值应为https://goproxy.cn,direct，否则私有域名（如git.internal.company）也会走代理并失败 - 临时验证代理是否真起作用：执行
GOPROXY=https://goproxy.cn,direct go mod download—— 加前缀可绕过当前环境变量，直接测试
还原缓存 ≠ 重装所有模块：优先复用 $GOPATH/pkg/mod/cache/download
真正耗时的是从网络拉取 .zip 和 .mod 文件，而解压后的源码树（即 $GOPATH/pkg/mod 下的 example.com/repo@v1.2.3 目录）只是中间产物。只要保留 $GOPATH/pkg/mod/cache/download，就能跳过网络阶段，秒级重建可用缓存。
-
$GOPATH/pkg/mod/cache/download是只读缓存池，按module@version存储原始下载物（@v/v1.2.3.zip等），go mod download会优先复用它 - 备份时只需保留该目录，还原后执行一次
go mod download即可重建$GOPATH/pkg/mod下的解压结构 - 别误删
$GOPATH/pkg/sumdb：它存校验数据，删了会导致后续go mod verify重新联网查 sum.golang.org
项目重命名或模块路径变更后，缓存“存在却不可用”
当你把 go.mod 里的 module github.com/old/name 改成 github.com/new/name，旧缓存不会自动映射到新路径——Go 不会猜你改名了，它只认 go.mod 声明的 module path。
- 现象：
go list -m all显示旧路径模块仍存在，但新路径下go build报cannot find module - 根本原因：缓存目录名由 module path + version 决定，路径一变，Go 就当它是全新模块
- 解决方法不是硬清全部缓存，而是精准清理：
rm -rf $GOPATH/pkg/mod/github.com/old/name@*，再跑go mod download - 顺手检查
go mod graph输出里是否混着新旧路径模块——若有，说明某个间接依赖还引用着旧路径，需用replace或升级该依赖
CI/CD 或多项目共享缓存时，GOMODCACHE 必须显式配置
默认 GOMODCACHE 落在 $GOPATH/pkg/mod，但不同用户、不同 shell 的 $GOPATH 可能不同。在构建机或容器中，若未统一设置，每个 job 都会生成独立缓存，失去复用意义。
- 在 CI 脚本开头固定设置：
export GOMODCACHE=/shared/go-mod-cache，然后挂载同一目录到所有 job - 验证是否生效：
go env GOMODCACHE应输出你指定的路径，而非$GOPATH/pkg/mod - 注意权限：确保 Go 进程对
/shared/go-mod-cache有读写权，否则go mod download会静默失败 - 别和
GOCACHE混用：GOCACHE控制编译中间产物（.a文件），与模块缓存无关；两者可同目录但逻辑隔离
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
