真正固定依赖版本需 go.mod + go.sum + 正确操作流程共同实现，仅修改 require 版本号不够，因 go mod tidy 或 build 可能因依赖冲突、go.sum 缺失或缓存缺失而自动升降级。
Go 项目里 go.mod 中的 require 行默认不锁定版本，go get 或 go build 可能自动升级间接依赖，导致构建结果不一致。要真正固定依赖版本，关键不是只写死 require 的版本号，而是靠 go.mod + go.sum + 正确的模块操作流程共同实现。
为什么只改 require 版本号不够
手动把 require github.com/sirupsen/logrus v1.9.0 改成 v1.8.1 看似锁定了，但 Go 工具链仍可能在下次 go mod tidy 或 go build 时因其他依赖需要更高版本而回退或升级——尤其当该版本在 go.sum 中缺失、或本地缓存里没对应 zip 时，Go 会尝试解析最新兼容版本。
真正起约束作用的是：go.sum 文件记录了每个模块版本的校验和，而 go mod download 和构建过程会严格比对；同时 go.mod 中的 require 版本必须是 go list -m all 能解析出的有效版本。
- 仅改
require行不运行go mod tidy，该版本不会进入构建图 - 改完后没执行
go mod download，CI 构建时可能拉不到对应 zip，触发自动降级/升级 -
go.sum缺失某行？Go 默认允许（除非设置GOSUMDB=off），但会警告；缺失 + 网络可访问 = 可能重新计算并写入新哈希，带来不确定性
用 go get 显式指定版本并更新 go.mod 和 go.sum
这是最可靠、符合 Go 官方工作流的锁定方式：让 Go 工具链自己解析、下载、校验、记录完整信息。
立即学习“go语言免费学习笔记（深入）”；
例如，要把 golang.org/x/net 锁定到 v0.14.0：
go get golang.org/x/net@v0.14.0
这条命令会做三件事：更新 go.mod 中的 require 行、下载该版本到本地 module cache、将对应校验和写入 go.sum。之后再执行 go mod tidy，它只会清理未被引用的模块，不会动已明确指定的版本。
- 不要用
go get -u，它会升级所有依赖，包括间接依赖 - 如果提示
require ...: version "v0.14.0" invalid，说明该 tag 不存在或未发布，可用go list -m -versions golang.org/x/net查看可用版本 - 想锁定 commit hash？用
go get golang.org/x/net@3a52a15b6e75，Go 会自动转为 pseudo-version（如v0.0.0-20230928155457-3a52a15b6e75）并写入go.mod
检查是否真的锁定了 —— 验证 go list -m all 和 go.sum
运行以下命令，确认目标模块版本已固化且无冲突：
go list -m all | grep 'golang.org/x/net'
输出应为精确匹配你期望的版本（如 golang.org/x/net v0.14.0），而非 v0.14.0 加上 +incompatible 或其它后缀（除非你明确接受 incompatible 模式）。
再检查 go.sum 是否包含该模块的完整条目：
grep 'golang.org/x/net' go.sum
应看到两行：一行是 zip 包哈希，一行是 go.mod 文件哈希。缺任意一行，都意味着校验链不完整。
- 若
go list -m all显示版本正确，但go.sum没对应行，说明模块虽被引用，但尚未被校验下载；此时运行go mod download补全 - 若多个
require行指向同一模块不同版本，Go 会按最小版本选择器（MVS）选一个，go list -m all显示的是最终选用的版本，不是require列表里的全部 - CI 环境务必启用
GOFLAGS="-mod=readonly"，防止意外修改go.mod或go.sum
固定版本的本质不是“写死字符串”，而是让 Go 的模块解析器、下载器、校验器形成闭环。任何绕过 go get / go mod tidy 直接编辑 go.mod 的做法，都容易在下次模块操作中被覆盖——尤其是团队协作或 CI 场景下，go.sum 的缺失或不一致往往比版本号写错更难排查。
