校验失效的根本原因是哈希不匹配，源于本地缓存、代理污染或上游tag被篡改；最有效解决路径是清理modcache、删除go.sum后tidy重建，辅以GOPROXY=direct验证及go mod verify上线前校验。
校验失效不是网络问题，也不是权限不足，而是本地缓存、代理返回内容或上游模块被篡改导致的哈希不匹配。直接清理 + 重建是最有效路径。
go clean -modcache 后必须删 go.sum 再 tidy
go clean -modcache 清掉的是 $GOPATH/pkg/mod 下所有模块缓存，但 go.sum 里还存着旧哈希，下次 go get 或 go mod tidy 会拿新下载的包和旧哈希比对，必然失败。
- 执行
go clean -modcache - 手动删掉项目根目录下的
go.sum（别留空文件） - 再跑
go mod tidy或go get -u，让工具重新生成完整且一致的go.sum - 注意：
go.mod不受影响，你声明的依赖版本仍保留
GOPROXY=direct 能快速定位代理污染
国内常用代理如 https://goproxy.cn 有时缓存滞后或被注入内容，导致 zip 包哈希变化。临时切到 direct 是最干净的验证方式。
- Linux/macOS：运行
export GOPROXY=direct - Windows：运行
set GOPROXY=direct - 再执行
go mod tidy，如果成功，说明是代理问题 - 修复建议：换用
https://proxy.golang.org，或配置多源回退GOPROXY=https://goproxy.cn,https://proxy.golang.org,direct
作者 force push tag 时只能用 commit hash 锁定
这是最隐蔽的情况：v1.2.3 tag 对应的代码被重写过，go.sum 里存的是旧哈希，但新 zip 已不可逆。此时任何清理都无效。
立即学习“go语言免费学习笔记（深入）”；
- 查
go.sum中对应行，确认模块路径和版本 - 运行
go mod download -json <module>@<version>看实际指向哪个 commit - 拿到 commit hash（如
a1b2c3d）后，执行go get <module>@a1b2c3d - 后续
go mod tidy会自动写入 pseudo-version，不再依赖 tag
go mod verify 是上线前必跑的校验动作
它不下载也不修改，只比对本地缓存和 go.sum 是否一致。CI/CD 流水线里漏掉这步，等于放行被篡改的依赖。
- 在构建前加一行：
go mod verify - 输出
all modules verified才继续 - 若失败，说明有人动过缓存、或
go.sum被手改过 —— 此时不应跳过，而该触发告警并阻断构建 - 注意：
go mod verify不处理缺失条目，缺条目得靠go mod tidy补全
真正麻烦的从来不是报错本身，而是错误背后那个没被发现的 tag 覆盖、代理污染或缓存混用——它们不会每次都触发，但一旦触发，就可能在某个凌晨三点的发布窗口里突然冒出来。
