能，但只在缓存校验文件（.info、.ziphash）损坏时有效；自建代理返回内容与官方sum不一致且本地缓存残留旧校验数据时，清理可强制重新生成校验值，但若代理本身错误则需同步其上游缓存。
go clean -modcache 能不能修好 checksum mismatch？
能，但只在缓存校验文件（.info、.ziphash）损坏时有效。自建代理（如 Nexus、JFrog）返回的模块 zip 与官方 sum 不一致，而本地缓存里还存着旧的校验数据，就会触发 checksum mismatch 错误——此时 go clean -modcache 会删掉所有 cache/download 下的 .info/.ziphash 文件，强制下次拉取时重新生成校验值。
注意：go clean -modcache 不删 go.sum，也不改代理配置。如果代理本身返回了错误内容（比如缓存未刷新、签名未同步），清理本地缓存只是治标；得同步代理后端的模块元数据或清空其上游缓存。
- 执行前先确认错误是否真来自缓存：运行
go build -v，看到类似verifying github.com/some/pkg@v1.2.3: checksum mismatch才适用 - 别在 CI 中无条件执行：它会让所有构建首次变慢，且无法规避代理层问题
- 验证是否生效：清理后运行
go list -m -f '{{.Dir}}' github.com/some/pkg，路径应为新解压目录，而非旧缓存残留
GOPROXY 配成自建站 + direct 为什么还报 404？
因为 GOPROXY 的 fallback 机制被绕过了——常见于漏配 GONOPROXY 或代理服务本身不支持 direct 回源。
Go 要求当代理返回 404/403 时才走 direct，但如果自建代理对私有域名（如 git.internal.company.com）直接返回空响应、超时或重定向到登录页，Go 就不会触发 fallback，而是卡住或报错。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 必须显式设置
go env -w GONOPROXY=git.internal.company.com，让 Go 绕过代理直连该域名 - 检查代理日志：确认它对私有模块请求是否返回真实 404（HTTP status 404），而不是 HTML 登录页（status 200）
-
GOPROXY=https://nexus.example.com/repository/goproxy,direct中的direct是关键字，不能拼错或加空格
go mod tidy 不下载依赖，是不是缓存坏了？
大概率不是。自建代理环境下，go mod tidy 卡住或静默退出，更常因网络策略或代理鉴权失败，而非本地缓存损坏。
典型表现是终端无输出、无错误、CPU 占用低——说明 go 命令根本没发 HTTP 请求，卡在 DNS 解析或 TLS 握手阶段。
- 加
-v参数看真实行为：go mod tidy -v，若卡在Fetching行，说明网络层阻塞 - 用
curl -v https://nexus.example.com/repository/goproxy/github.com%2Fgolang%2Fexample/@v/list手动测代理连通性 - 私有模块需确保
go env GOPRIVATE包含对应域名，否则 Go 会跳过校验并拒绝从非官方源拉取
如何避免自建代理缓存污染扩散到开发机？
关键不是清理频率，而是隔离和验证。本地 $GOPATH/pkg/mod 是最终落点，但污染源头在代理层；开发机只是受害者。
推荐做法是把代理校验逻辑前置：每次推送新模块到自建代理前，先用 go list -m -json all 对比官方源 checksum，再触发代理同步。
- CI 构建时禁用本地缓存复用：
go clean -modcache+go mod download，避免带毒缓存进入构建节点 - 开发机上设
go env -w GOSUMDB=off仅用于调试（必须配合GOPRIVATE），否则校验失效会导致 silent 拉错版本 - 定期用
go mod verify检查项目完整性，它不依赖代理，只比对go.sum和当前缓存内容
.info 但没更新 .ziphash，这种组合在本地很难靠 go clean -modcache 彻底解决，得两边同时动作。 
