go.mod 的 require 不是白名单，真正依赖范围由 go list -m all 输出决定，白名单必须覆盖全部直接与间接依赖，并配合 replace 拦截高风险包、ci 门禁校验及不可变原子配置更新。
go.mod 中的 require 语句不是白名单，只是声明
很多人误以为在 go.mod 里写死 require github.com/sirupsen/logrus v1.9.0 就完成了白名单控制——其实这只是告诉 Go “我需要这个版本”，但不阻止其他模块间接引入 v2.0.0 或恶意 fork。真正起作用的是你是否允许它进入构建图。
关键判断点：执行 go list -m all 输出的每一行，只要没被显式 replace 或 exclude，就属于当前构建的实际依赖链。白名单机制必须覆盖这个完整列表，而非仅看 go.mod 的 require 块。
- 用
go list -m all | grep -v "indirect" | cut -d' ' -f1提取所有直接依赖模块路径 - 对每个路径做白名单校验（比如正则匹配
^github\.com/(company|trusted-org)/） - 对
indirect依赖也需扫描——它们可能来自你未察觉的 transitive 传递，比如github.com/evil/pkg被github.com/good/lib间接拉入
用 go mod edit -dropreplace + replace 配合实现强制重定向
白名单审核不能只靠“允许什么”，更要主动拦截“不允许什么”。Go 没有原生的 denylist 语法，但可用 replace 把高风险包强制指向空模块或审计过的 fork。
例如，发现项目中某依赖偷偷引入了 github.com/evil/pkg（哪怕只是 indirect），应在根模块 go.mod 中写：
replace github.com/evil/pkg => github.com/your-org/empty-module v0.0.0
这样 Go 构建时会拒绝解析该模块内容（empty-module 里不导出任何符号），且 go build 会报错，阻断构建流程。
- 先运行
go mod edit -dropreplace=github.com/evil/pkg清理旧规则，避免冲突 - 再执行
go mod edit -replace=github.com/evil/pkg=github.com/your-org/empty-module@v0.0.0 - 最后用
go list -m all | grep evil验证是否彻底消失——别只扫go.mod文件
CI 流程中必须串联 go vulncheck 和许可证扫描
白名单审核不是一次性的配置动作，而是每次 go mod tidy 后必须触发的门禁检查。否则 go mod tidy 可能自动升级到含 CVE 的版本（如从 v1.2.0 升到 v1.3.0），而你完全不知情。
推荐 CI 步骤顺序：
go mod tidy-
go vulncheck -mode=mod -vulnerable-only（非零退出即失败） -
go-licenses csv . > licenses.csv，然后脚本校验每行许可证是否在组织白名单内（如禁止AGPL-3.0、SSPL） - 自定义脚本遍历
go list -m all，比对模块路径是否命中预设正则白名单
注意：go.sum 文件无法替代上述三步——它只保证哈希一致，不防漏洞、不审许可证、不控来源。
动态白名单更新时，避免中间件热加载导致规则不一致
有些团队把白名单存在配置中心（如 etcd、Consul），由中间件监听变更并 reload。这看似灵活，但极易出问题：reload 过程中，新旧规则指针切换若未用 atomic.Value 包裹，正在处理的请求可能看到部分旧规则、部分新规则，造成放行/拦截逻辑错乱。
正确做法是把白名单规则封装为不可变结构体，并用 atomic.Value 存储其指针：
type IPWhitelist struct {
nets []*net.IPNet // 预解析好的 CIDR 列表
}
var whitelist atomic.Value // 存 *IPWhitelist
// 加载新规则时：
newWL := &IPWhitelist{nets: parsedNets}
whitelist.Store(newWL)
中间件里直接调用 whitelist.Load().(*IPWhitelist) 获取当前快照，全程无锁读取。
- 不要在 handler 里实时查 DB 或 HTTP API 加载白名单——单次延迟放大为 RTT，QPS 上千时雪崩
- 不要用
map[string]bool存 IP 网段——它不支持 CIDR，且并发写需加锁，性能差 - 白名单配置项如
"127.0.0.1"、"::1"、"10.0.0.0/8"必须统一用net.ParseCIDR或 fallback 到/32//128解析
go mod tidy 的最小版本选择算法天生倾向拉取更高版本——无论那个版本是否在你最初写的 go.mod 里。
