go.mod中写死完整语义化版本号（如v1.9.3）才是真锁定，replace可强制覆盖版本但需校验checksum，禁用go get -u、提交go.sum并审计间接依赖才能确保构建稳定。
go.mod 里写死版本号才是真锁定
Go 不会“自动升级”，但默认行为会让 go get 或 go mod tidy 拉取满足语义化版本约束的最新兼容版——比如你写 github.com/sirupsen/logrus v1.2.0，它可能悄悄变成 v1.9.3，只要没改 go.mod 文件本身。这不是 bug，是 Go 的设计逻辑：它只认 go.mod 里声明的版本，而这个声明如果只写大版本（如 v1）或带波浪线（~1.2.0），就留出了漂移空间。
真正阻止小版本漂移，必须把版本写成完整语义化格式：
- 手动编辑
go.mod，把require github.com/sirupsen/logrus v1改成require github.com/sirupsen/logrus v1.9.3 - 保存后运行
go mod download确保该版本已缓存 - 再执行
go mod verify检查校验和是否匹配go.sum
之后所有命令（包括 go build、go test）都会坚持用 v1.9.3，除非你手动改 go.mod 或显式执行 go get 带新版本号。
replace 能绕过版本解析规则，但要注意 checksum 校验
当你需要锁定到某个未打 tag 的 commit，或者想用私有 fork 替代上游时，replace 是唯一能覆盖语义化版本解析的方式。它比 require 优先级更高，整个模块图都会走这条路径。
常见写法：
-
replace github.com/sirupsen/logrus => github.com/sirupsen/logrus v1.9.3（指向已发布版本） -
replace github.com/sirupsen/logrus => ./local-logrus（本地路径，适合调试） -
replace github.com/sirupsen/logrus => github.com/sirupsen/logrus v0.0.0-20230510152458-6b72e3a001f6（精确 commit）
注意：如果目标仓库后续发布了同名 tag（比如 v1.9.3），Go 仍会校验其 checksum 是否与 go.sum 一致；不一致直接报错，不是静默替换。
别让 go get -u 成为版本漂移的源头
很多团队所谓“自动升级”，其实只是 CI 或本地脚本里写了 go get -u。这个命令会递归升级所有直接和间接依赖到 latest，完全无视 go.mod 里的约束。
安全做法是彻底禁用无参数的 -u：
- 更新单个依赖时，必须显式指定版本：
go get github.com/gorilla/mux@v1.8.0 - CI 流水线中加检查：
go mod tidy -v && git status --porcelain go.mod go.sum | grep -q '.' && exit 1，防止未提交的变更流入构建 - 把
go.sum始终纳入 Git，它是依赖内容的不可篡改快照，缺失或忽略它等于放弃校验
间接依赖的版本不受你直接控制，但能审计和干预
你锁死了 github.com/gin-gonic/gin v1.9.1，但它依赖的 golang.org/x/net 可能被另一个包拉进 v0.19.0，而你根本没在 go.mod 里写它——这就是间接依赖。Go 的最小版本选择（MVS）机制会挑一个能同时满足所有需求的版本，通常是最高那个。
要发现这类漂移：
- 运行
go list -m all查看完整依赖树，搜关键词定位版本来源 - 用
go mod graph | grep golang.org/x/net看谁引入了它 - 若需统一，可在
go.mod中显式require golang.org/x/net v0.18.0，再跑go mod tidy
真正的难点不在怎么锁，而在意识到：你写的每一行 require 都只是“请求”，最终版本由整个依赖图共同决定；go.sum 是最后防线，但它只管校验，不管逻辑兼容性。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
