Go依赖版本锁定本质是通过go.mod明确声明精确语义化版本（如v1.9.3）并由go.sum校验内容一致性，只要不手动执行go get或go mod tidy等更新命令，版本绝不会变更；replace可强制绑定到伪版本实现更细粒度控制，但需慎用于生产。
Go 不会自动升级依赖，所谓“限制只能用特定版本”本质是确保 go.mod 明确声明该版本，且 go.sum 强制校验其内容一致性——只要不手动触发更新命令，Go 工具链就绝不会换版本。
直接在 go.mod 中写死完整语义化版本号
这是最可靠、最透明的锁定方式。Go Module 的版本解析完全以 go.mod 中 require 行的字面值为准，不搞模糊匹配。
- 打开
go.mod，找到类似require github.com/sirupsen/logrus v1.9.0的行 - 把它改成带完整 patch 号的明确版本，例如：
require github.com/sirupsen/logrus v1.9.3 - 保存后运行
go mod download确保该版本已缓存；再执行go mod verify确认校验和匹配 - 此后所有
go build、go test、go mod tidy都会坚持用v1.9.3，除非你再次编辑go.mod或运行go get
用 replace 强制绑定到某个 commit（含伪版本）
当你需要绕过 tag、测试未发布修复、或锁定到某个无 tag 的提交时，replace 比改 require 更精确——它直接跳过版本解析，直指 commit。
- 在
go.mod末尾添加：replace github.com/sirupsen/logrus => github.com/sirupsen/logrus v0.0.0-20230510152458-6b72e3a001f6 - 这个伪版本（pseudo-version）由时间戳 + commit hash 构成，比
v1.9.3更细粒度，也更抗篡改 -
replace优先级高于require，整个模块图都会生效；但注意：如果远程仓库后来打了同名 tag（如v1.9.3），Go 仍会校验其 checksum 是否与go.sum一致，不一致就报错 - 别用
replace做长期生产锁定——它绕过了语义化版本意图，容易让团队成员误判真实依赖状态
禁用隐式升级行为：避开 go get -u 和未提交的 go.sum
很多“版本漂移”不是 Go 自动干的，而是人手滑或 CI 流程松导致的。关键是要切断非受控更新路径。
立即学习“go语言免费学习笔记（深入）”；
- 永远不要裸跑
go get -u——它会递归升级所有直接+间接依赖到 latest，极易破坏兼容性 - 升级单个依赖时，必须显式指定版本：
go get github.com/sirupsen/logrus@v1.9.3 -
go.sum必须提交到 Git：它是不可编辑的校验快照，删了会导致后续构建失败；CI 中建议加检查：go mod tidy -v && git status --porcelain go.mod go.sum | grep -q '.' && exit 1 - 如果你看到
go.mod里某依赖写着v1.9（缺 patch 号），说明之前用了go get github.com/xxx@v1.9这种宽松写法——立刻补全为v1.9.3并go mod tidy
真正容易被忽略的是间接依赖：你没 import 它，但它被其他包拉进来了。Go 默认用最小版本选择（MVS），所以即使你锁死了 A，B 仍可能悄悄引入 C 的新版。查清来源得靠 go mod graph | grep c-name 或 go list -m all | grep c-name ——不摸清这点，光锁主依赖只是半截子事。
