流水线中无需重复执行go mod init，因go.mod已提交时init会失败；应由开发者手动触发go mod tidy并提交更新后的go.mod和go.sum，ci仅验证一致性并检查退出码。
流水线里执行 go mod init 不是必须步骤，多数情况下反而会破坏依赖一致性
流水线中是否需要重复执行 go mod init
不需要。只要项目根目录已存在 go.mod，CI 就不该再跑 go mod init —— 它不会“修复”缺失的依赖，只会报错或覆盖已有模块路径。
- 若
go.mod已提交，go mod init会直接失败（go: cannot initialize new module in existing module root） - 若误删了
go.mod，应从 Git 恢复，而非重新 init；否则模块路径可能不一致，导致下游项目 import 失败 - 某些旧脚本用
go mod init .试图“自动推导路径”，但 Go 不支持点号路径，会 fallback 到默认名（如mod），后续所有 import 都会出错
go mod tidy 在 CI 中的正确触发时机
go mod tidy 应仅在代码变更引入新 import 或删除旧 import 后手动触发，并提交更新后的 go.mod 和 go.sum；CI 运行时只做验证，不做修改。
- CI 中执行
go mod tidy -v并检查退出码：非零表示代码里有未声明的 import 或声明了但没用到的依赖，应视为构建失败 - 禁止在 CI 中加
-w（写入文件）或搭配git commit自动提交——这会让依赖变更脱离代码审查 - 如果项目用了
replace指向本地路径，CI 必须确保该路径存在且内容一致，否则go mod tidy会报cannot find module
私有依赖和代理配置对流水线的影响
CI 环境没有 GOPROXY 或 GOSUMDB 配置时，go get 或 go build 可能卡住、超时，或校验失败。
- 必须在 CI 前设置
GOPROXY=https://proxy.golang.org,direct（或公司内部 proxy），避免直连 GitHub/GitLab -
GOSUMDB=off仅限内网无校验服务场景；更稳妥的是用GOSUMDB=sum.golang.org+ 公司自建 sumdb，或配置GOSUMDB=off时同步关闭go mod verify - 使用
replace指向私有 Git 地址（如git.example.com/internal/pkg）时，CI 必须预装 SSH key 或配置 HTTPS token，否则go mod download会失败
真正容易被忽略的是 go.sum 文件的校验行为：它默认启用，且不随 go mod tidy 自动刷新；如果依赖包发布后篡改了历史 tag，CI 第一次拉取会成功，第二次可能因校验和不匹配而中断——这不是 bug，是设计使然。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
