可靠检验依赖完整性的方式是执行 go mod verify 并清空本地模块缓存后构建；go mod tidy 不校验 checksum、不验证 go.sum 有效性，故无法保证完整性。
直接结论：用 go mod verify + 清空本地模块缓存后 go build，才是检验依赖完整性的可靠方式。仅靠 go mod tidy 或本地能跑通，根本不算数。
为什么 go mod tidy 不能代表依赖完整
go mod tidy 只是同步 go.mod 和实际 import 的依赖列表，并下载缺失模块到本地缓存（$GOPATH/pkg/mod）。它完全不校验 checksum、不检查网络不可达时能否 fallback、也不验证 go.sum 是否被篡改或过期。
- 常见错误现象：本地
go mod tidy && go build成功，CI 上却报verifying github.com/xxx@v1.2.3: checksum mismatch - 根本原因：
go.sum里记录的哈希值与代理返回的实际模块内容不一致，而tidy不触发校验 - 正确做法：必须在无缓存、无历史模块干扰的前提下，重新拉取并校验全部依赖
执行纯净环境自测的三步操作
所谓“纯净”，是指模拟一个全新开发者首次克隆项目后的构建流程——不复用任何本地已有模块。
- 清空模块缓存：
go clean -modcache（注意：这会删除所有已下载模块，慎用于日常开发） - 强制重新下载并校验：
go mod download && go mod verify；前者拉取所有require项，后者逐个比对go.sum中记录的哈希 - 最终构建验证：
go build ./...（用./...覆盖全部子命令和 main 包，避免漏测）
GO111MODULE=on GOPROXY=direct GOSUMDB=off 这组配置不是用来“跳过校验”的
很多人误以为设成 GOPROXY=direct 就能绕过代理问题，其实它只是让 Go 直连原始仓库（如 GitHub），但此时 GOSUMDB=off 会彻底关闭哈希校验——等于主动放弃完整性保障。
立即学习“go语言免费学习笔记（深入）”；
- 真实需求场景：排查是否因代理缓存脏数据导致校验失败，应临时改为
GOPROXY=https://proxy.golang.org,direct并保留GOSUMDB=sum.golang.org - CI/CD 中推荐固定配置：
GOPROXY=https://goproxy.cn,direct（国内可用）+GOSUMDB=sum.golang.org，不关校验 - 若
go mod verify报错，优先检查go.sum是否被手动删减或go mod graph是否暴露了未声明的间接依赖
容易被忽略的关键点
依赖完整性不是“能不能编译通过”，而是“换一台机器、换一次时间、换一个网络环境，是否仍能复现相同构建结果”。go.sum 文件必须提交进 Git，且不能只靠 go mod tidy 更新——每次 go get 或升级依赖后，务必运行 go mod verify 确认无误再提交。
