新依赖引入必须经「依赖负责人」和「领域 owner」共同审批，pr需明确go get命令、问题解决说明、替代方案对比、许可证类型；ci强制校验require与go.sum一致性、模块哈希、高危漏洞，并禁用上线replace。
团队必须在 PR 合并前完成依赖引入的显式审批，不能靠 go mod tidy 自动补全绕过审核。
谁有权批准新依赖引入
新 require 行（尤其是首次引入外部模块）必须由至少一名「依赖负责人」+ 一名「领域 owner」共同 approve。前者关注安全性、许可证兼容性、维护活跃度；后者确认该依赖是否真正解决当前问题，而非重复造轮子或掩盖设计缺陷。私有模块（GOPRIVATE 范围内）也需同样流程，不能因“内部可用”就跳过评估。
PR 中必须包含哪些依赖说明
提交者在 PR 描述里要明确写清：
-
go get命令完整执行语句（例如：go get github.com/go-sql-driver/mysql@v1.14.0），不能只写“升级了 mysql 驱动” - 该依赖解决的具体问题（如：“替换
database/sql原生扫描逻辑，避免 struct 字段名大小写敏感导致的 nil panic”） - 替代方案对比（比如：为什么不用标准库
json而选github.com/json-iterator/go？列出 benchmark 数据或已知 bug 编号） - 许可证类型（
MIT/Apache-2.0/GPL-3.0），若为非宽松协议，需法务同步确认
CI 卡点必须检查的三项内容
GitHub Actions 或其他 CI 流水线中，以下检查失败即阻断合并：
-
go list -m all | grep -E '^\s*[a-zA-Z0-9./_-]+@' | wc -l输出数量与go.mod中require行数一致（防手动编辑go.mod漏写go.sum） -
go mod verify返回 0（确保所有模块哈希未被篡改） -
govulncheck -mode=imports ./...无高危漏洞（CVE 评分 ≥ 7.0），若有则需在 PR 中附修复 plan 或豁免理由
replace 指令的使用限制
replace 只允许用于本地调试，且必须满足：
- 仅指向同仓库内子目录（如
replace example.com/shared => ../shared），禁止指向绝对路径或~/路径 - 上线前必须移除，或替换为真实版本号（如
v0.3.1），CI 中可加校验：grep -q "replace" go.mod && (echo "replace found, reject"; exit 1) || true - 若因紧急 patch 需临时
replace远程模块，必须同时提交 issue 链接到上游，并约定回退时间（最长不超过 2 个 sprint）
最容易被忽略的是 replace 的隐式传播——它不会出现在 go list -m all 输出里，但会影响整个构建链路；另一个盲区是 indirect 依赖的变更，哪怕没动 require，go.mod 更新后也要重新走一遍审批流程。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
