go mod tidy 不该无条件自动执行，尤其在敏捷迭代中；应由开发者本地执行并提交 go.mod/go.sum，ci 仅运行 go mod verify 验证一致性，禁止动态推导依赖，确保构建基于稳定快照。
go mod tidy 在 CI/CD 流水线里该不该自动执行
不该无条件自动执行，尤其在敏捷迭代中频繁合入 PR 时。go mod tidy 会修改 go.mod 和 go.sum，若未加约束，容易引发隐性变更：比如自动升级间接依赖、引入新校验和、甚至因 MVS 算法选版差异导致构建行为漂移。
实操建议：
- CI 中只运行
go mod verify验证go.sum完整性，不写入文件 - 强制要求 PR 提交前本地执行
go mod tidy，且提交变更（含go.mod和go.sum） - 流水线加检查：对比当前分支与 main 的
go.mod差异，若新增/删除require行但无对应代码变更，阻断合并 - 避免在
go build前加go mod tidy—— 构建应基于已提交的依赖快照，而非动态推导
如何让 feature 分支用临时版本而不污染 main 分支的 go.mod
直接改 go.mod 里的 require 版本号是错的。main 分支的 go.mod 必须保持稳定，feature 分支的依赖变更不能反向污染它。
正确做法是用 replace 指令局部覆盖：
- 在 feature 分支根目录下执行：
go mod edit -replace github.com/org/pkg=../pkg（指向本地未发布的模块） - 或替换为特定 commit：
go mod edit -replace github.com/org/pkg=github.com/org/pkg@5a1b2c3 -
replace只影响当前模块构建，不会被go mod tidy自动清理，也不上传到远程仓库（除非你手动提交） - 上线前必须删掉
replace行，并通过go get github.com/org/pkg@v1.2.4锁定正式版本
GOPROXY 和 GOPRIVATE 配合时的常见陷阱
设了 GOPROXY=https://goproxy.cn,direct 却仍拉不到私有模块？大概率是 GOPRIVATE 没配对或格式错。
关键细节：
-
GOPRIVATE值必须是模块路径前缀，不是 URL；例如私有仓库地址是git.internal.company/project/foo，则GOPRIVATE应设为git.internal.company，不是https://git.internal.company - 多个前缀用逗号分隔，**不能有空格**：
go env -w GOPRIVATE=git.internal.company,github.com/my-org - 如果模块路径含子域名（如
team.git.internal.company），需显式列出，git.internal.company不会自动匹配子域名 -
GOPROXY=...direct中的direct是 fallback 关键字，表示“对GOPRIVATE覆盖的模块，跳过代理直连”，不是字符串 “direct”
敏捷发布中 go.sum 文件为什么不能忽略
go.sum 不是“校验缓存”，而是构建一致性契约。忽略它等于放弃可重现构建——这在每日多次发布的场景里是灾难性的。
典型问题：
- 开发者 A 本地
go mod download下载了github.com/some/pkg v1.2.0的某个 zip，B 下载了另一个镜像源的同版本 zip，二者哈希不同 →go.sum冲突，CI 构建失败 - 没提交
go.sum，新成员 clone 后go build自动下载依赖，但实际拿到的是不同时间点的模块快照，可能含未公开的 patch - 安全扫描工具依赖
go.sum中的哈希比对已知漏洞版本，缺失则漏报
必须把它和 go.mod 一起提交，且禁止任何脚本自动重写它——哪怕只是换行符差异也会导致校验失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
