go项目发布前必须确保go.mod和go.sum精确锁定依赖：运行go mod tidy同步文件，禁用ci自动修改，移除replace指令，校验go.sum完整性，并将三者与git commit hash共同作为版本快照。
Go模块依赖本身不参与版本发布决策，但它是自动化发布流水线的校验锚点——所有语义化版本升级、go.mod 更新、go.sum 锁定都必须在发布前完成且不可变。
go mod tidy 和 go mod vendor 必须在发布前执行并提交
本地开发时改了 import 路径或加了新包，go.mod 可能没更新；CI 构建时 go build 会静默拉取最新版，导致构建产物与你本地测试的不一致。
- 每次准备发布（如打 tag 前）必须运行
go mod tidy，确保go.mod和go.sum精确反映当前代码所用依赖 - 若项目要求完全离线构建或审计严格，用
go mod vendor生成vendor/目录，并把该目录提交进 Git——CI 中需额外加-mod=vendor参数 - 禁止在 CI 中自动执行
go mod tidy或修改go.mod：这会让流水线“偷偷改代码”，破坏可追溯性
语义化版本 bump 必须同步更新 go.mod 的 module 行和 require 版本
比如你用 Go 工具自动 bump 到 v2.1.0，但 go.mod 里还是 module myapp，没改成 module myapp/v2，下游项目 require myapp v2.1.0 就会失败。
- 主模块升级大版本（v1 → v2）时，
go.mod的module行必须带/v2后缀，且所有内部 import 也要同步调整 - 发布补丁版本（v1.0.0 → v1.0.1）时，
go.mod通常不变，但要确认require中间接依赖的版本是否被go mod tidy收敛过 - 用
go list -m -json all可导出当前解析出的完整依赖树，用于发布清单归档
CI 中禁止自动更新 go.sum，但必须校验其完整性
CI 流水线里看到 verifying github.com/some/pkg@v1.2.3: checksum mismatch 错误，大概率是有人提交了没跑 go mod tidy 的代码，或者用了被污染的代理缓存。
- 始终设置
GOSUMDB=off或GOSUMDB=sum.golang.org+ 配置可信 CA，避免因网络问题中断流水线 - 必须在构建前加一步：
go mod verify，失败即退出；不要只靠go build的隐式校验 - 如果使用私有代理（如 Athens），需在 CI 中显式配置
GOPROXY=http://athens:3000并验证其返回的.zip和.info响应是否匹配go.sum
多模块项目中 replace 指令不能进入正式发布分支
开发时用 replace github.com/team/lib => ./internal/lib 很方便，但若这个 replace 还留在 go.mod 里就打 tag，下游项目 go get 会失败——因为 ./internal/lib 路径在他们机器上不存在。
- 所有
replace必须在发布前移除，改用真实版本号（如github.com/team/lib v1.4.0） - 推荐做法：用 CI 脚本在发布流程中自动检测
go.mod是否含replace，有则报错 - 内部模块协作建议走独立仓库 + Git Tag 发布，而非本地 replace —— 这样版本可追踪、可缓存、可审计
真正容易被忽略的是：go.sum 不只是校验文件，它也是版本快照。一次发布对应唯一一组 go.mod + go.sum + Git commit hash，三者缺一不可。删掉 go.sum 提交、或让 CI 自动重写它，等于撕掉了版本的出生证明。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
