go.sum必须提交，否则ci会因哈希不一致报checksum mismatch；它强制校验模块内容完整性，而非版本锁定，缺失将导致构建漂移。
必须把 go.mod 和 go.sum 当作源码一样提交，且每次依赖变更后立即 go mod tidy -v 并提交两文件——这是唯一能防止“本地能跑、CI 报错”的底线操作。
为什么 go.sum 被忽略会导致构建漂移
它不是可选的校验文件，而是 Go 工具链强制比对的哈希锁：一旦没提交，CI 拉取代码时会按当前 go.mod 重新解析并生成新 go.sum，而不同 Go 版本、不同 GOPROXY 响应顺序、甚至不同时间点的模块归档内容都可能微变，导致哈希不一致。常见现象包括：
-
go build在 CI 中报verifying github.com/xxx@v1.2.3: checksum mismatch - 同一 commit，开发者 A 的
go list -m all显示github.com/xxx v1.2.3，B 却显示v1.2.4 -
go mod download成功但go mod verify失败，退出码为 1
go mod tidy -v 必须作为每次依赖变更的收尾动作
它不只是“整理依赖”，而是同步三件事：go.mod 中缺失的间接依赖、go.sum 中缺失的哈希、以及本地缓存中未下载的模块归档。不加 -v 参数时，它可能静默跳过某些校验，尤其在 GOPROXY 不稳定时。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 新增 import 后，必须运行
go mod tidy -v，不能只靠go build自动补全 - 删除未用包后，
go mod tidy -v会从go.mod移除对应 require 行，并清理go.sum中冗余哈希 - 团队约定：所有 PR 提交前，CI 流水线第一行必须是
go mod tidy -v && git diff --exit-code go.mod go.sum，有差异则拒绝合并
GOPROXY 配置必须透传到 CI 和每个开发者终端
代理不一致会让同一 go.mod 下载出不同归档（比如 proxy.golang.org 返回的是官方归档，而私有 Athens 返回的是内部镜像归档），直接破坏 go.sum 可信度。
- 禁止在
.bashrc里写export GOPROXY=https://proxy.golang.org—— 应统一写入项目级配置，如.envrc或devcontainer.json的remoteEnv - GitHub Actions 中显式声明：
env: GOPROXY: https://goproxy.cn,direct，避免继承 runner 默认值 - 私有模块必须配合
GOPRIVATE=git.company.com/*，否则 Go 会绕过代理直连，触发 401 或超时
真正容易被忽略的点：go version 声明和 GO111MODULE=on 的绑定
go.mod 文件首行的 go 1.21 不只是注释——它决定了模块解析器的行为边界。如果 CI 使用 Go 1.22，而 go.mod 写的是 go 1.21，某些模块的 replace 或 exclude 规则可能被忽略；更隐蔽的是，未设 GO111MODULE=on 时，旧版 Go 会 fallback 到 GOPATH 模式，go mod tidy 根本不生效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
