Go modules是当前唯一推荐的依赖管理方式，自Go 1.11引入、1.16起默认启用，取代vendor/和dep等已废弃工具；初始化用go mod init，依赖版本通过go get@vX.Y.Z或编辑go.mod+go mod tidy控制，replace/exclude用于替换或排除依赖，go.sum必须提交至Git并严格校验。
Go modules 是当前唯一推荐的依赖管理方式
Go 1.11 引入 modules，1.16 起默认启用，GO111MODULE=on 已成事实标准。不用 vendor/ 目录或 dep 等旧工具——它们不再维护，且与 Go 官方工具链（如 go test、go run）行为不一致，容易导致本地能跑、CI 报错。
初始化项目只需一条命令：go mod init example.com/myapp。模块路径不必真实可访问，但应具备语义（避免用 main 或空字符串）。之后所有 go get、go build 操作都会自动维护 go.mod 和 go.sum。
如何精确控制依赖版本（含间接依赖）
go.mod 中的 require 行默认只记录直接依赖，但 go.sum 锁定全部传递依赖的校验和。要升级某依赖到特定版本，用 go get foo/bar@v1.2.3；若想降级或修复已知漏洞，直接编辑 go.mod 并运行 go mod tidy 即可同步清理未使用项并补全缺失项。
- 替换私有库或 fork：用
replace指令，例如replace github.com/some/lib => ./local-fix或replace github.com/some/lib => git.example.com/fork/lib v1.0.0 - 排除有问题的间接依赖：用
exclude（慎用，仅限临时规避严重 bug） - 查看完整依赖图：运行
go list -m all；查某包被谁引入：go mod graph | grep some-lib
CI/CD 中必须校验 go.sum 且禁止 go mod download 后修改
go.sum 不是“锁文件”而是校验快照，每次 go build 或 go test 都会验证下载包内容是否匹配。CI 流程中若跳过校验（如删掉 go.sum 或设 GOSUMDB=off），就失去防篡改能力。
立即学习“go语言免费学习笔记（深入）”；
常见错误操作：
- 在 CI 中执行
go mod download后提交生成的go.sum—— 这会导致本地开发时校验失败，因为go.sum应由开发者运行go mod tidy后提交 - Git 忽略
go.sum—— 它必须进版本库，否则不同机器拉代码后依赖可能不一致 - 用
go get -u自动升级所有依赖 —— 会绕过语义化版本约束，极易引入破坏性变更
跨团队协作时模块路径与发布标签的硬性约定
模块路径即 go.mod 第一行的字符串，它决定了 go get 的导入路径。一旦发布 v1.x 版本，就不能再随意修改路径，否则下游无法升级。版本号必须打 Git tag，格式严格为 v1.2.3（带 v 前缀），否则 go list -m -versions 查不到，go get @latest 会 fallback 到伪版本（v0.0.0-20240101000000-abcdef123456），难以追溯。
小版本迭代（v1.2.x → v1.3.0）需保证向后兼容；主版本升级（v1 → v2）必须变更模块路径，例如从 example.com/lib 改为 example.com/lib/v2，否则 Go 工具链无法区分。
真正麻烦的是私有模块代理配置 —— 如果团队用 GOPRIVATE=*.internal，务必确保所有匹配域名的请求都走可信代理或直接 Git，否则 go get 会尝试访问 proxy.golang.org 导致失败或泄露。
