必须确保GOSUMDB=sum.golang.org且运行go mod verify验证，首次生成go.sum需在全新克隆仓库中执行go mod tidy，vendor目录须清空缓存后生成并完整提交。
go get 时如何避免拉到被污染的模块
直接依赖 proxy.golang.org 或默认 GOPROXY 设置，不等于安全。代理只缓存转发，不校验内容完整性——恶意包可能已混入缓存，或被中间人劫持替换。关键不是“从哪下”，而是“下下来后有没有验证”。
- 强制启用校验：确保环境变量
GOSUMDB=sum.golang.org（不可设为off或空）；该服务由 Go 团队签名维护，会拒绝未签名或哈希不匹配的模块 - 禁用不安全代理：避免设置
GOPROXY=https://goproxy.cn等未经审计的镜像站作为唯一源；如必须用，应叠加官方校验：GOPROXY=https://goproxy.cn,direct，并保留direct回退路径用于比对 - 检查
go.sum是否被绕过：运行go mod verify，若输出all modules verified才可信；若报missing hash或mismatch，说明已有模块未被记录或已被篡改
go.sum 文件本身是否可信？怎么确认它没被伪造
go.sum 可被手动编辑、提交或覆盖，它只是“本地记录”，不是防篡改凭证。它的作用是提供比对基线，但基线本身需来自可信源头。
- 首次生成必须源自干净的
go mod tidy：在全新 clone 的仓库中执行，且确保当前GO111MODULE=on、GOSUMDB有效；不要复用他人提交的go.sum而不验证 - 每次
go get后，go.sum会自动追加新条目，但不会删除旧条目——若发现某行哈希突然变更，或出现大量新增/删减，需人工核对对应模块的官方发布页（如 GitHub tag 页面）是否真有该版本 - CI/CD 中必须运行
go mod download -json | grep -q 'error'或go list -m all配合go mod verify，仅靠go build成功不能说明依赖干净
vendor 目录能防恶意依赖吗？怎么用才真正起效
vendor 是离线备份手段，不是安全机制。如果 go mod vendor 基于已被污染的 go.sum 或缓存，那 vendor 里装的就是带毒依赖。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 生成前先清空：执行
rm -rf vendor && go clean -modcache，再跑go mod vendor，避免复用本地缓存中的可疑包 - vendor 必须提交完整目录：包括所有子模块的
.git（如有）、go.mod和go.sum—— 缺一不可；否则 CI 拉取时可能跳过校验直接解压 - 构建时显式启用：用
go build -mod=vendor，而非依赖GOWORK或隐式行为；同时确保GO111MODULE=on，防止 fallback 到 GOPATH 模式加载额外包
哪些信号表明模块可能已被篡改
没有绝对“一眼识别”的特征，但以下现象值得立即停用并溯源：
立即学习“go语言免费学习笔记（深入）”；
-
go mod graph显示陌生域名模块（如github.com/0xdeadbeef/utils），且不在go.mod显式 require 中——可能是间接依赖被注入 -
go list -m -u all报出大量[vX.Y.Z]版本号后带-0.202607...这类伪版本，尤其当原始仓库并无对应 tag 时，说明模块来源不可信 - 某个模块的
go.sum条目哈希长度异常（非 64 字符 SHA256），或包含h1:以外的校验前缀（如h2:），这是 Go 早期 bug 或非标准工具生成的痕迹
最易被忽略的是：把 go.sum 当作信任锚点，却忘了它本身需要被可信流程生成。真正的防线在初始化那一刻——干净的环境、有效的 GOSUMDB、不跳过的 go mod verify。其他都是补丁。
