不能靠手动编辑go.sum锁定哈希，它是由Go工具链自动生成的校验快照；真正锁定依赖需固定模块路径+精确版本（如v1.9.3或commit hash），再通过go get等命令触发自动拉取与哈希写入。
不能靠手动编辑 go.sum 来“锁定哈希”，它不是配置文件，而是 Go 工具链自动生成的校验快照。真正起作用的是你如何声明和更新依赖——哈希只是结果，不是入口。
怎么让 go.sum 记下你想要的哈希
想让某个模块固定在特定内容上，唯一可靠的方式是固定它的模块路径 + 精确版本标识（语义化版本或 commit hash），然后让 go 命令自动拉取、校验、写入 go.sum。
- 用完整带
@的版本：比如go get github.com/sirupsen/logrus@v1.9.3，而不是go get github.com/sirupsen/logrus（后者可能拉 latest，且不更新go.mod中的版本号） - 没打 tag 的仓库，必须用 commit hash：
go get github.com/gorilla/mux@3f5e24b6，Go 会自动转成类似v0.0.0-20230101000000-3f5e24b6abcd的伪版本，并记录对应哈希 - 执行后立刻检查
go.sum是否新增了该模块的h1:行；如果没变，可能是 proxy 缓存或本地 module cache 干扰，加-x参数看真实 fetch 行为：go get -x github.com/xxx@v1.2.3
为什么 go.sum 里同一模块出现多行
这不是错误，是 Go 校验机制的正常表现：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
github.com/some/pkg v1.2.3 h1:abc...是模块源码 ZIP 的哈希 -
github.com/some/pkg v1.2.3/go.mod h1:def...是它自己的go.mod文件哈希（用于验证其依赖声明是否被篡改） - 极少数情况下还会有第三行，对应它的
go.sum（几乎不用管） - 如果看到同一模块多个
h1:行对应不同版本（如v1.2.0和v1.5.0），说明项目里确实间接引入了多个版本——这是合法的，Go 会各自校验，但你要意识到这增加了攻击面
CI/CD 中防止 go.sum 被意外改动
构建阶段的核心原则是：只读，不写。
- 禁止在 CI 流程中运行
go get、go mod tidy或任何可能修改go.mod/go.sum的命令（除非你明确在做依赖升级） - 构建前先运行
go mod verify，它会强制校验所有模块哈希是否与go.sum一致，不一致直接失败 - 确保
go.sum提交进 Git —— 如果它被忽略或未提交，不同机器拉下来的依赖可能哈希不匹配，导致构建失败或行为不一致 - 不要手动删
go.sum行，哪怕看起来“多余”；清理无用条目应交给go mod tidy -v，它只删未被go.mod引用的哈希（但保留go.mod校验行）
最易被忽略的一点：go.sum 只保证“内容一致性”，不验证“来源可信性”。它防不了你第一次就引入恶意包，也防不了私有仓库里被投毒的模块。真正的防线在源头——严格审查 require 行、定期跑 govulncheck、配合 GOSUMDB=sum.golang.org 验证公共模块哈希是否进入透明日志。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
