go.mod 和 go.sum 不可直接提交到主干分支，因不同 go 版本、goproxy 或执行时间会导致 go.sum 校验和不一致，引发 ci 构建失败；正确做法是 ci 使用统一 go 版本、执行 go mod download 验证依赖，并禁用 go mod tidy，pr 阶段检查 git status --porcelain go.mod go.sum 非空则拒绝合入。
为什么 go.mod 不能直接提交到主干分支？
企业流水线里最常踩的坑，是把开发机上生成的 go.mod 和 go.sum 直接合入主干。问题在于：不同 Go 版本、不同 GOPROXY 设置、甚至不同时间点执行 go get，都可能导致 go.sum 中校验和不一致，触发 CI 构建失败或模块替换异常。
正确做法是确保所有依赖版本在提交前已锁定且可复现：
- CI 流水线必须使用统一 Go 版本（如
1.21.10），并在构建前执行go mod download验证所有模块可拉取 - 禁止在 CI 中运行
go mod tidy—— 它会修改go.mod，导致构建态与代码态不一致 - 推荐在 PR 检查阶段加入
git status --porcelain go.mod go.sum，非空则拒绝合入
如何让私有模块在 CI 中稳定解析？
企业常用私有 Git 仓库（如 Gitee、GitLab）托管内部模块，但 go get 默认不信任自建域名，容易报错 unknown revision 或 no matching versions。
关键不是改 ~/.gitconfig，而是通过环境变量和配置双保险：
- 设置
GOPRIVATE=git.example.com/internal/*，让 Go 跳过 checksum 验证和 proxy 代理 - 在 CI 环境中配置
git config --global url."https://token:x-oauth-basic@git.example.com/".insteadOf "https://git.example.com/"，解决认证问题 - 若用 SSH 克隆，需确保 CI Agent 有对应私钥且
~/.ssh/config正确映射 Host 别名
go build -mod=readonly 在流水线中有什么实际作用？
这个参数不是锦上添花，而是防止“幽灵依赖”混入构建的关键开关。它强制 Go 工具链不修改 go.mod，哪怕代码里引用了未声明的模块，也会直接报错 require ...: not found in go.mod。
CI 构建命令应始终带上它：
go build -mod=readonly -o myapp ./cmd/myapp
配合 GO111MODULE=on 使用，能提前暴露两类问题：
- 开发者本地漏执行
go mod tidy，导致新引入包未写入go.mod - 误用
_导入触发副作用（如注册 driver），但该包未显式 require
多模块仓库（monorepo）下如何避免依赖污染？
一个 Git 仓库含多个 service（svc-a、svc-b）时，常见错误是根目录放一个 go.mod，结果 svc-b 的依赖被 svc-a 的 go mod tidy 意外升级。
企业级实践是「每个 service 独立模块」：
- 每个子目录（如
services/svc-a）下都有自己的go.mod，且module名为完整路径（如git.example.com/monorepo/services/svc-a） - 内部模块引用用相对路径（
replace git.example.com/monorepo/lib => ../lib），而非./lib—— 后者在 CI 拉取单个子目录时会失效 - CI 构建每个 service 前，先
cd services/svc-a && go mod download，隔离网络和缓存影响
真正麻烦的从来不是语法，而是当 go.sum 里某一行校验和突然变了，而没人记得上周谁动过那个私有库的 tag。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
