Go modules 缓存默认存于$GOPATH/pkg/mod，只读且由工具链管理；GOPATH不再存源码但决定缓存位置；需配置GOPROXY和GOSUMDB加速下载并避免校验失败；replace仅编译期映射，不影响缓存；清理用go clean -modcache，诊断用go mod download -x。
Go modules 缓存默认开启，无需额外配置，但缓存位置、代理策略和本地调试方式直接影响构建速度与可重现性。
Go modules 缓存存在哪？GOPATH 还管用吗？
Go 1.11+ 默认使用 $GOPATH/pkg/mod 存储模块缓存（不是 $GOPATH/src）。这个路径是只读的，由 Go 工具链自动管理；手动修改或删除其中内容会导致下次 go build 重新下载。
-
GOPATH仍影响缓存位置，但仅用于定位pkg/mod，不再存放源码 - 可通过
go env GOPATH查看当前路径，用go env GOMODCACHE直接查缓存根目录 - 多 workspace 场景下，所有项目共享同一
GOMODCACHE，节省磁盘与网络
如何加速模块下载？配 GOPROXY 和 GOSUMDB
国内直连 proxy.golang.org 常超时或失败，必须配置镜像代理。同时 GOSUMDB 验证失败也会阻塞首次 go mod download。
- 推荐设置：
go env -w GOPROXY=https://goproxy.cn,direct（direct表示对私有域名走直连） - 关闭校验（仅限内网可信环境）：
go env -w GOSUMDB=off；更安全的做法是用sum.golang.org的国内镜像：go env -w GOSUMDB=sum.golang.org+https://goproxy.cn/sumdb/sum.golang.org - 若公司有私有模块（如
git.internal.company.com/mylib），确保其域名不在GOPROXY列表中，否则会被错误转发
本地模块怎么“缓存”？用 replace 替换后还能复用吗？
replace 是开发期临时替换依赖路径的机制，它不改变缓存行为，但会影响 go mod download 是否触发远程拉取。
立即学习“go语言免费学习笔记（深入）”；
- 例如：
replace github.com/some/lib => ../some-lib—— 此时go build直接读本地文件，完全跳过缓存与网络 - 但执行
go mod vendor或 CI 构建时，若未保留replace，会回退到远程版本；建议在go.mod中注释说明用途，避免误删 -
replace不影响其他项目的缓存，也不会把本地路径写进pkg/mod；它只是编译期的符号映射
缓存出问题了怎么清理和诊断？
缓存损坏虽少见，但可能表现为 checksum mismatch、missing git hash 或反复重下同一版本。
- 清空全部缓存：
go clean -modcache（注意：这会清掉所有模块，下次构建需重新下载） - 只删某个模块：
rm -rf $(go env GOMODCACHE)/github.com/some/pkg@v1.2.3 - 诊断下载过程：
go list -m all看解析结果，go mod download -x显示每一步 fetch 日志 - 若某模块始终拉不下来，先确认
go env GOPROXY是否生效（curl $GOPROXY/github.com/some/pkg/@v/v1.2.3.info测试）
真正容易被忽略的是：go.sum 文件本身不是缓存，而是校验快照；它和 GOMODCACHE 协同工作，但各自独立更新。改了 go.mod 后忘记 go mod tidy，就可能导致 go.sum 滞后，进而触发不必要的重新校验与下载。
