go.sum校验失败时，go命令比对模块路径+版本+源码zip的SHA256哈希值；若本地缓存、代理返回或作者re-tag导致zip内容变更，即触发checksum mismatch错误。
go.sum 文件校验失败时，go 命令到底在比什么
Go 的 go.sum 不是简单记录版本哈希，而是按模块路径 + 版本 + 源码归档（zip）的 SHA256 校验和分三列存储。一旦你本地缓存的包内容、代理返回的内容、或模块作者重新发布同版本（re-tag）的 zip 包，校验就会失败——go build 或 go get 就会报 checksum mismatch。
常见错误现象：verifying github.com/some/pkg@v1.2.3: checksum mismatch，后面跟着两行 hash，第一行是 go.sum 里存的，第二行是当前下载到的。
- 不是网络问题，也不是 GOPROXY 配置错（除非代理本身缓存了脏包）
- 不是你改了代码导致的——
go.sum校验的是依赖包自身，不是你的项目源码 - 模块作者如果用
git tag -f v1.2.3后重新推送到 GitHub，再被 Go 模块代理抓取，就可能触发此问题
手动修复 go.sum 的安全前提和操作步骤
不能直接删 go.sum 或盲目 go mod tidy，那会引入未经验证的依赖。正确做法是让 Go 工具链“重新生成可信校验和”，但前提是确认新内容可信。
- 先确认该模块是否真被作者重发布：访问
https://proxy.golang.org/github.com/some/pkg/@v/v1.2.3.info，看Time字段是否晚于你上次拉取时间 - 检查模块仓库的
v1.2.3tag 是否被 force-push 过（GitHub 上 tag 页面会提示 “This tag was modified”） - 如果确认可信，运行
go clean -modcache清掉本地 module cache（避免复用旧 zip） - 再执行
go mod download，它会重新下载并写入新的校验和到go.sum - 最后
go mod verify确认无误
为什么 go mod tidy 有时反而让问题更糟
go mod tidy 本质是同步 go.mod 和实际 import 使用，它会自动添加缺失依赖、删除未用依赖，但**不保证重校验已有依赖的 go.sum 条目**。如果你的 go.sum 里混着旧 hash 和新 zip，tidy 可能跳过校验、甚至把冲突条目留着不动。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 它不会主动更新已存在但 mismatch 的条目——这是设计使然，防止静默覆盖
- 若你刚
go get -u升级某个间接依赖，而它的子依赖发生了 re-tag，tidy可能只更新顶层模块，漏掉深层 mismatch - 真正需要的是
go mod download或go build触发的完整校验流程，不是依赖整理流程
CI/CD 中绕过校验的风险与临时方案
某些 CI 场景下（如私有 proxy 不稳定、或 vendor 目录被强制要求一致），有人想用 GOFLAGS="-mod=readonly" 或 export GOSUMDB=off 跳过校验。这不是修复，是自欺。
-
GOSUMDB=off会让所有模块失去校验，等价于关闭供应链完整性保护 -
-mod=readonly只禁止修改go.mod/go.sum，但 mismatch 仍会报错，不解决根本问题 - 真正稳健的做法是：在 CI 前加一步
go mod verify && go mod download，失败则中断构建，而不是屏蔽错误
校验失败从来不是 Go 的 bug，而是它在认真告诉你：你正在加载的字节码，和最初声明的不一致。这个“不一致”背后，可能是意外，也可能是攻击——别急着删文件，先查清楚来源。
