go模块依赖防篡改的关键在于主动校验：go.sum仅记录哈希，必须通过ci中显式执行go mod verify来比对校验，且需提交go.sum至git、审慎管控proxy/replace、警惕未经审计的require依赖。
Go 模块依赖被篡改的风险，本质不是“能不能防”，而是“你有没有让防护机制真正起作用”。go.sum 文件本身不提供主动防护，它只记录哈希——如果没人校验，它就只是个摆设。
go mod verify 必须在 CI 中显式执行
默认情况下 go build 完全不检查 go.sum 是否匹配，它只下载模块并缓存。这意味着：本地开发时删掉 go.sum 再 go build 也能成功，但你实际拉下来的代码可能已被替换。
-
go mod verify是唯一能触发校验的命令，它会比对本地缓存模块的哈希与go.sum记录是否一致 - CI 流水线里必须加入
go mod verify，且失败时中断构建；仅靠go mod download不够 - 别依赖
GO111MODULE=on或go.mod存在就以为安全——它们控制的是模块启用，不是校验开关 - 如果你用的是私有代理（如自建 Athens），确保其配置了
sumdb验证，否则go mod verify可能绕过远程校验
go.sum 不是锁文件，删了再 tidy 很危险
go.sum 是每个依赖版本的哈希快照，不是像 package-lock.json 那样可再生的“锁”。删掉它再跑 go mod tidy，看似干净，实则可能引入不同 commit。
- 上游若删除了 tag（比如 v1.2.0 被 force-push 替换），
go mod tidy会拉取新 commit 并生成新哈希，而旧go.sum已失效 - 即使 tag 保留，不同机器上
go mod tidy可能因网络顺序、proxy 缓存差异，解析出不同 commit（尤其当依赖未打 tag 时） - 正确做法是：把
go.sum提交进 Git，禁止手动编辑；更新依赖时用go get或go mod edit，再go mod tidy自动同步哈希 - CI 中若发现
go.sum被修改，应视为可疑变更，需人工确认而非自动提交
依赖来源必须可控，proxy 和 replace 都要审
Go 默认走 proxy.golang.org，但它不验证作者身份，只保证内容一致性。恶意包只要没被 sumdb 收录或标记为恶意，就能通过代理分发。
- 生产环境建议设置
GOPROXY=https://proxy.golang.org,direct，末尾direct是 fallback，但会跳过 sumdb 校验——慎用 - 用
replace替换依赖时，务必确认目标仓库可信；replace github.com/foo/bar => ./local/bar这种本地路径替换，在 CI 中会被忽略，导致行为不一致 - 私有模块必须配好
git config或~/.netrc，否则认证失败时 Go 可能退回到公共 proxy，拉取同名但恶意的公开包 - 定期运行
govulncheck ./...，它依赖官方 vuln DB，但要注意 DB 更新延迟——不能替代go mod verify
最常被忽略的一点：校验链从 go.sum 开始，但终点是你的 go.mod ——如果某行 require 指向一个你从未审计过的模块，哪怕哈希全对，它本身也可能就是恶意入口。真正的防护不在工具链末端，而在你敲下 go get 前那一秒的判断。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
