go.sum不能直接删除重生成，因其作为依赖链可信锚点，删除后可能引入被篡改或下线版本，导致校验失效和安全风险。
go.sum 文件校验失败时为什么不能直接删掉重生成
因为 go.sum 不只是记录哈希值的“快照”，它还隐含了模块依赖链的可信锚点。删除后执行 go mod download 或 go build 会重新拉取所有模块，但新生成的 go.sum 可能包含已被篡改或已下线的版本（比如某模块作者撤回了恶意提交但未打新 tag），此时 Go 工具链不会主动比对历史记录，相当于放弃校验依据。
常见错误现象：verifying github.com/some/pkg@v1.2.3: checksum mismatch，说明本地缓存的模块内容与 go.sum 中记录的 h1: 值不一致——这要么是网络传输损坏，要么是远程模块被恶意替换。
- 先运行
go clean -modcache清空本地模块缓存，再试go mod download - 若仍失败，检查该行
go.sum记录是否被手动修改过（比如误删了末尾的空格或换行） - 确认模块仓库是否真的发布了
v1.2.3：访问https://proxy.golang.org/github.com/some/pkg/@v/v1.2.3.info，看返回的Version和Time是否合理
如何验证 go.sum 中某一行是否对应真实发布的模块
Go 的校验逻辑依赖两个来源：官方代理（proxy.golang.org）和校验服务器（sum.golang.org）。单靠本地 go.sum 文件无法自证清白，必须交叉验证。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
go list -m -json all | jq '.Sum'查当前构建中每个模块实际参与校验的哈希值（注意：仅限已加载模块） - 手动请求
sum.golang.org：例如curl https://sum.golang.org/lookup/github.com/some/pkg@v1.2.3，返回应包含h1:哈希及签名信息 - 对比
go.sum中该行是否与sum.golang.org返回完全一致（包括空格、换行、大小写）；任何差异都意味着该行不可信
启用 GOPROXY=direct 时 go.sum 校验还生效吗
生效，但风险陡增。设置 GOPROXY=direct 会让 Go 直接从模块源站（如 GitHub）拉代码，跳过官方代理和校验服务器的中间校验层。此时 go.sum 仍会参与本地完整性比对，但前提是：你信任源站 DNS、HTTPS 证书、Git 仓库权限体系，且源站未被入侵。
典型问题场景：
- 私有模块未配置
goproxy且未启用GOINSECURE，导致go get失败后退回到 direct 模式，悄悄绕过校验 - 公司内部镜像未同步
sum.golang.org数据，却设置了GOPROXY=http://internal-proxy，造成校验缺失 -
go.sum中某行是github.com/xxx@v1.0.0 h1:...，但 direct 拉下来的代码实际是作者在 tag 后又 force-push 覆盖过的 commit
安全底线：生产环境禁止无条件设 GOPROXY=direct；若必须用，需配合 GOVERDIR 锁定可信 commit，或自行部署校验服务。
CI 流程中如何自动化检测 go.sum 异常变更
关键不是“有没有变”，而是“谁变了、为什么变、是否授权”。把 go.sum 当作敏感配置文件对待，而非可忽略的生成物。
推荐做法：
- 在 PR CI 中加入检查步骤：
git diff origin/main -- go.sum | grep -E '^[+-]' | grep -v '^\+\+|^--' || true
，捕获新增/删除行（非仅空白符变更） - 对每条新增的
go.sum行，调用curl -s "https://sum.golang.org/lookup/$(echo $LINE | cut -d' ' -f1)@$(echo $LINE | cut -d' ' -f2)" | grep -q 'h1:'验证其在官方校验库中存在 - 禁止直接
go mod tidy提交go.sum：要求所有变更必须关联明确的go.mod修改（如升级依赖、添加新模块），并在 PR 描述中说明原因
最容易被忽略的一点：团队共用的 go.sum 文件里混入了开发机本地未提交的 dirty module（比如 replace 指向本地路径），这类行在 CI 中根本不会触发校验，却可能让整个构建失去可重现性。
