白名单管控是go项目多团队协作中防止依赖失控的核心机制，要求require显式声明精确版本、禁用通配符与indirect依赖、ci启用goflags="-mod=readonly"、replace须白名单批准、go.sum必须提交并校验。
大型 Go 项目一旦进入多团队协作阶段，依赖失控会直接导致构建失败、安全漏洞漏检、版本不一致等线上事故。白名单管控不是“加一层审批”，而是把依赖决策权从个人开发者收回到工程规范中——它必须可执行、可验证、不可绕过。
go.mod 中的 require 必须显式声明且禁止通配符
Go Modules 默认允许 go get github.com/sirupsen/logrus 这类无版本操作，结果是 go.mod 里可能写入 v1.9.3，但下次 go mod tidy 可能悄悄升级成 v2.0.0+incompatible。这不是 bug，是设计行为。
- 所有
require行必须带精确语义化版本（如github.com/sirupsen/logrus v1.9.3），禁用@latest、@master、@main - CI 流程中用
go list -m -f '{{.Path}} {{.Version}}' all提取全部依赖，再比对预设白名单文件（如deps/whitelist.json）；不匹配则exit 1 - 禁止在
go.mod中使用// indirect标记的依赖出现在白名单外——它们往往是隐式引入的高危间接依赖
GOFLAGS="-mod=readonly" 是 CI 中防止 go mod 自动修改的硬开关
很多团队在 CI 中只跑 go build，却忘了 go test 或 go list 命令在某些条件下会触发自动 go mod download 或 go mod tidy，从而污染 go.mod。这不是开发者的错，是 Go 工具链默认行为。
- CI 环境必须设置
GOFLAGS="-mod=readonly"，任何试图修改go.mod的操作都会立即报错：go: updates to go.mod needed, disabled by -mod=readonly - 本地开发时也建议 alias
go="go -mod=readonly"，提前暴露问题 - 这个 flag 不影响
go run或go build，只拦截写操作，零成本防御
私有模块和 replace 指令必须被白名单显式批准
replace 在本地联调时很香，但上线前若未清理，会导致构建环境拉不到源码、go.sum 校验失败、甚至因路径映射错误引入旧版代码。更危险的是，有人用 replace 直接指向私有 Git 分支（如 replace example.com/lib => git@git.internal/lib.git dev-branch），这完全绕过了版本控制与审计。
- 白名单配置需包含两类条目：标准模块路径（如
github.com/gorilla/mux）和受信私有路径（如git.company.com/internal/auth） - 所有
replace必须出现在白名单中，且格式严格匹配：replace A => ./local/path或replace B => git.company.com/repo v1.2.0 - CI 中运行
go mod graph | grep replace+ 正则校验，未授权的replace直接阻断发布
go.sum 不是附属文件，它是白名单策略的落地凭证
很多团队只校验 go.mod，却忽略 go.sum。但攻击者完全可以保留合法的 require 行，篡改对应模块的 .zip 包并重签哈希——这时 go.sum 就是唯一防线。
- 白名单策略必须要求：每个模块的
go.sum文件随代码提交，禁止.gitignore掉 - CI 构建前执行
go mod verify，失败即终止；该命令会校验所有模块的 checksum 是否与本地go.sum一致 - 对于多 module 项目，每个子模块的
go.sum都要独立校验，不能只验根模块——子模块的go.sum才真正约束其自身依赖
白名单真正难的不是写规则，而是让所有人无法“临时绕过”。GOFLAGS、CI 强制校验、go.sum 不可删——这些才是让策略落地的关键钉子。一旦某个环节允许人工 override，整套机制就退化成文档。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
