go mod verify不能替代go.sum提交，必须将go.sum与go.mod一同提交至git，否则校验会因缺失文件失败；它仅比对本地缓存与go.sum记录，不保证首次引入的依赖安全。
go mod verify 不能替代 go.sum 提交
校验失败往往不是命令没用，而是 go.sum 没进 Git。go mod verify 只比对本地缓存和 go.sum 记录，如果团队成员本地没有该文件，或者它被 .gitignore 过滤掉了，命令会直接报错 “missing hash in go.sum” 或跳过部分模块。
- 必须把
go.sum和go.mod一起提交，且禁止在 CI 脚本里加go mod tidy -v后自动提交——这会绕过人工审查 -
go.sum中每行包含两个哈希：h1:开头的是模块 zip 包哈希，go.mod行是模块根目录的哈希；两者缺一不可 - 如果某次
go mod tidy新增了间接依赖，go.sum会多出对应条目，此时要确认新增模块来源是否可信（比如是否来自已知组织、是否有活跃维护）
vendor 目录不是“可选优化”，而是防丢兜底手段
当 proxy.golang.org 临时不可达、模块作者删库、或私有代理缓存污染时，go mod download 会卡住或失败。这时 vendor 就是唯一能继续构建的路径。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 执行
go mod vendor后，所有依赖复制到项目根目录下的vendor文件夹，不再依赖远程源 - CI 构建必须显式启用 vendor 模式：
go build -mod=vendor，否则 Go 仍会尝试读取$GOPATH/pkg/mod - vendor 目录体积大，但不要压缩或 .gitignore 它——Git LFS 或对象存储归档更合适；关键是保证它和
go.mod版本严格对应
GOSUMDB 和 GOPROXY 必须显式配置，不能依赖默认
Go 默认使用 sum.golang.org 校验哈希，但在国内或企业内网常因网络策略失败，导致 go build 直接退出。这不是 bug，是安全机制主动拦截。
- 设置
GOSUMDB=off是危险操作，等于关闭供应链攻击防护；正确做法是换为可信镜像：GOSUMDB=sum.golang.google.cn -
GOPROXY建议设为https://goproxy.cn,direct（国内）或https://proxy.golang.org,direct（海外），direct是 fallback，确保私有模块仍可拉取 - 若用私有 proxy（如 Athens），需同步配置
GOSUMDB指向其内置 checksum service，否则校验会失败
CI 中验证顺序决定能否真正防住篡改
很多团队只在最后跑 go mod verify，但此时依赖早已下载完成，校验失败只能告警，无法阻断构建。真正有效的防线要前置。
- CI 第一步应运行
go mod download，它会在下载时实时校验go.sum并对接GOSUMDB；失败则立即终止 - 第二步再跑
go mod verify，确认本地缓存未被后续操作污染（比如有人手动改过$GOPATH/pkg/mod下的源码） - 不要在
go test阶段才首次触发依赖下载——测试失败可能掩盖了更早的完整性问题
go list -m all 定期扫描、govulncheck 扫漏洞、人工 review go.mod 新增项，这些动作和 go mod verify 同样关键。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
