go.sum校验失败应运行go mod download -v定位问题模块，再通过go mod edit -replace、GOPROXY=direct或go clean -modcache+go mod download修复，切勿手动删改go.sum。
go.sum 文件校验失败时，go build 或 go get 报 checksum mismatch 怎么办
直接删 go.sum 不解决问题，反而可能掩盖依赖污染。真正要做的，是让 Go 工具链重新确认每个模块的哈希值是否与当前实际下载内容一致。
- 先运行
go mod download -v，看具体哪个模块校验失败（错误信息里会带模块名和期望/实际的h1:哈希） - 如果该模块是你本地修改过的（比如 fork 后改了代码但没发新 tag），就用
go mod edit -replace=module/path=../local/path替换，并运行go mod tidy重算哈希 - 如果是公共模块（如
golang.org/x/net）报错，大概率是代理源缓存脏了：临时关掉代理试一下——设置GOPROXY=direct再执行go mod download - 别手动编辑
go.sum，Go 不认手写的哈希；它只接受go mod tidy或go build自动写入的条目
为什么 go.sum 里同一模块会出现多行哈希
不是 bug，是 Go 的设计机制：一个模块在不同版本、不同引入路径（比如 indirect 依赖 vs 直接 require）、甚至不同校验算法（h1 vs go.mod 文件的 h1）下，都会单独存一行。
-
h1:开头的是模块 zip 包内容的 SHA256 哈希（主体校验） -
go.mod后面跟的h1:是该模块go.mod文件自身的哈希（用于检测 module 声明变更） - 如果某模块被多个其他模块间接引用，且版本不一致，
go.sum里就可能出现相同模块名、不同版本号的多行记录 - 删除某行后运行
go mod tidy，Go 会按当前go.mod中解析出的实际依赖图补全，不是简单“恢复原样”
go mod verify 验证失败但项目能跑，还要管吗
要管。能跑只是因为本地缓存里恰好有旧版 zip，不代表构建可复现——CI 环境或新机器上大概率失败。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
go mod verify检查的是go.sum记录的哈希是否与本地$GOPATH/pkg/mod缓存中对应模块的实际内容一致 - 常见诱因：你或同事手动改过某个依赖的本地缓存（比如进
pkg/mod/cache/download/...目录改了文件），或者用了非标准方式注入 patch - 修复方法不是跳过验证，而是清缓存 + 重拉：
go clean -modcache，再go mod download；注意这会清除所有模块缓存，适合排查，不适合日常 - CI 脚本里建议加
go mod verify作为检查项，早发现问题
私有模块或 Git 仓库未托管在标准域名时，go.sum 校验容易崩
因为 Go 默认把 Git URL 当作模块标识符，而不同写法（git.example.com/repo vs ssh://git@git.example.com/repo）会被视为不同模块，各自生成哈希，但实际内容一样——这就导致 go.sum 里重复、冲突、甚至漏写。
立即学习“go语言免费学习笔记（深入）”；
- 统一使用 HTTPS 形式声明模块路径（如
example.com/repo），并在~/.netrc或GIT_AUTH_TOKEN中配认证，避免混用 SSH - 在
go.mod里显式写replace example.com/repo => git.example.com/repo v1.2.3，确保工具链始终按同一路径解析 - 私有仓库启用 Go Proxy 支持（如 Athens 或自建 proxy）比直连 Git 更稳，proxy 返回的响应含标准
Content-SHA256头，go工具链更信任 - 别依赖
go get git.example.com/repo@main这种写法进生产，它绕过go.sum记录，下次go mod tidy可能丢掉校验条目
校验机制本身不复杂，难的是当多个模块、多种引入方式、私有源和代理层叠在一起时，哪一行 go.sum 对应哪个真实文件，很容易对不上。最稳妥的做法永远是：让 go 工具自己算，而不是人去猜或修。
