90%的Go编译失败源于go.mod与go.sum不一致、缓存污染或构建命令错误；checksum mismatch必须通过rm -f go.sum后go mod tidy重建校验和，禁用手动修改go.sum，CI中禁用GOSUMDB=off以保障可重现性。
Go 包依赖导致的编译失败，90% 不是代码写错了，而是 go.mod 和 go.sum 状态不一致、缓存污染或构建命令用错。直接删 go.sum + go mod tidy 能解决大部分问题，但得知道为什么这么干、什么时候不能这么干。
checksum mismatch 错误必须重建 go.sum
报错形如 verifying github.com/some/pkg@v1.2.3: checksum mismatch，说明本地下载的包内容和 go.sum 记录的哈希对不上。这不是网络问题，而是文件被手动改过或缓存混乱了。
-
go.sum必须由go mod tidy自动生成并提交，禁止手写、删减或复制粘贴 - CI 中设
GOSUMDB=off会绕过校验，但破坏可重现性，上线前务必关掉 - 私有模块未配
GOINSECURE或 git credential，可能 fallback 到不同源，导致哈希不一致 - 修复步骤：先
rm -f go.sum，再go mod tidy；若仍失败，加-x看实际下载 URL，确认是否命中了 fork 或镜像
go get 指定版本不生效？MVS 算法在“做主”
go get foo/bar@v1.2.3 并不锁定版本，而是告诉模块版本选择器（MVS）：“我接受 v1.2.3 及更高兼容版”。如果已有 v2.0.0+incompatible，它就不会降级回 v1.x。
- 检查 tag 是否真实存在：
curl -I https://proxy.golang.org/foo/bar/@v/v1.2.3.info - 想强制拉取指定 commit：
go get foo/bar@abcd123 - 彻底绕过 MVS 升级逻辑：
go mod edit -require=foo/bar@v1.2.3+go mod tidy - 避免用
go get -u—— 它无视go.mod约束，强行升级所有依赖
vendor 目录存在但 still 连网？-mod=vendor 没加
go mod vendor 只是把依赖复制进 vendor/，不会改变 Go 工具链默认行为。从 Go 1.14 起，go build 默认仍走 GOPROXY 校验或补全间接依赖。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 构建时必须显式加参数：
go build -mod=vendor - 每次修改依赖后，要重新运行
go mod vendor并git add vendor/ -
replace和exclude混用时，replace优先，但规则必须团队同步维护，否则本地能过 CI 报错
修改了依赖包源码却没生效？你在用 go build main.go
执行 go build main.go 是孤立编译单个文件，Go 会复用 $GOPATH/pkg/ 下已缓存的 .a 文件（比如你改了 server/server.go，但链接的仍是旧 server.a），导致 undefined: xxx。
- 正确做法：进项目根目录，用
go build -o ./bin/main .（注意结尾是.，不是main.go） - 更推荐用模块方式：
go mod init初始化后，go build始终基于当前源码，无隐式缓存干扰 - 快速诊断：
ls $GOPATH/pkg/$(go env GOOS)_$(go env GOARCH)/your-dep.a存在即可能被复用
真正麻烦的从来不是怎么修，而是循环依赖、replace 后插件加载失败、CGO 构建指纹不一致这类问题——它们不报错在表面，而藏在构建环境一致性里。一个 go list -m all 对不上，就足以让 plugin.Open 静静失败。
