checksum mismatch 表示 go.sum 校验和与下载内容不一致，需先运行 go mod verify 确认失败模块，检查 proxy 设置，清缓存重下；CI 中须校验 go.sum；定位问题依赖用 go list 和 go mod why；锁定间接依赖需手动 require；replace 需验证生效且避免嵌套。
报错说 checksum mismatch 怎么办
这表示 go.sum 里记录的校验和与当前下载内容不一致，不是网络问题就是依赖被篡改了。
- 先运行
go mod verify确认哪些模块校验失败；如果失败，说明本地缓存或远程源不可信 - 检查是否用了非官方 proxy（比如私有镜像），尝试临时设
GO_PROXY=https://proxy.golang.org,direct重试 - 不要手动删
go.sum行或改内容；若确认是误报（如上游强制重打了 tag），用go clean -modcache清缓存，再go mod download重建 - CI 流程中必须加
git status go.sum检查，防止有人漏提交导致环境不一致
go build 失败但没提示具体模块
常见于升级 Go 版本后，错误信息藏在深层依赖里，直接看第一行容易漏掉根因。
- 先执行
go list -m all | grep -E '\+incompatible|v[2-9]'，盯住带+incompatible或主版本 ≥ v2 的模块——它们最可能破坏兼容性 - 对疑似模块跑
go mod why -m github.com/some/pkg，它会输出一条调用链，比如main => github.com/A v1.2.0 => github.com/some/pkg v1.0.0 - 再对链上中间模块（如
github.com/A）执行go list -m -u，看它是否有新版已适配目标模块的新版 - 避免直接
go mod tidy：它可能按旧规则选版本，反而掩盖冲突；应先定位再干预
想锁定某个间接依赖的版本
Go 默认不把间接依赖写进 go.mod，所以 go mod tidy 不会保留你想要的版本。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须手动加
require行：在go.mod里写require github.com/sirupsen/logrus v1.9.3，哪怕没直接 import - 加完立刻运行
go mod tidy，它会把该版本纳入最小版本选择（MVS）并更新go.sum - 如果该模块被多个路径以不同版本引入，
go mod graph | grep logrus能快速看出谁拉了旧版，再针对性升级上游 - 注意：加
require后，该模块就变成“显式依赖”，后续go mod tidy不会删它，即使没人 import
replace 之后构建还是失败
replace 是临时接管，但容易因路径、循环或作用域出问题。
- 检查
replace目标是否真实存在且可构建：比如replace github.com/x/y => ./local，要确保./local下有合法go.mod - 运行
go list -m github.com/x/y，如果输出版本是(devel)，说明 replace 生效；如果是语义化版本，说明没生效（可能拼写错误或被其他 replace 覆盖） - 禁止嵌套 replace：A replace B，B 又 replace A，会导致解析死循环；用
go mod edit -json查所有 replace 规则，删冗余项 -
replace不传递给下游 module，如果你的项目是库而非应用，下游仍会拉原始版本——这种场景更适合 fork + 提 PR，而不是长期靠 replace
真正容易被忽略的是：Go 的依赖解析发生在构建前一瞬间，go list -m all 和 go mod graph 输出的版本，未必等于 go build 实际加载的版本。只要存在 replace 或 exclude，就得用 go list -f '{{.Module.Version}}' some/import/path 去验证运行时视角。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
