go.mod 中 require 行必须指定精确语义化版本（如 v1.2.3）或伪版本（v0.0.0-20220101000000-abcdef123456），Go 以此严格确定构建所用模块版本，而非依赖锁文件。
go.mod 中的 require 行如何指定精确版本
Go 模块版本不是靠“锁文件”生效，而是由 go.mod 文件中的 require 语句直接声明——只要写死版本号（如 v1.2.3），go build 和 go run 就会严格使用该版本。
常见错误是写成 require example.com/lib latest 或留空版本，这在 Go 中根本不合法；Go 要求每个 require 必须带明确语义化版本（vX.Y.Z）或伪版本（v0.0.0-20220101000000-abcdef123456）。
-
go get example.com/lib@v1.5.0会自动更新go.mod中对应行，并下载该版本到本地pkg/mod - 手动编辑
go.mod后，运行go mod tidy可校验依赖一致性，但不会“升级”已锁定的版本 - 如果模块未发布正式 tag，Go 会自动生成伪版本（如
v0.0.0-20231015123456-abcdef123456），它绑定具体 commit，同样具备确定性
为什么 go.sum 不是“锁文件”，但不可删
go.sum 记录的是每个模块版本对应的加密校验和（hash），用于防止依赖被篡改或意外替换。它不控制版本选择，只做完整性验证。
删除 go.sum 后首次 go build 会重新生成，但若此时网络中该模块已被恶意覆盖（比如同名同版本被重推），就可能引入风险。所以它虽不锁定版本，却是安全链上关键一环。
立即学习“go语言免费学习笔记（深入）”；
- 每次
go get或go mod download都会更新go.sum中对应条目 - CI 环境应校验
go.sum是否变更，避免未审核的依赖悄悄混入 - 不能用
go.sum回滚版本——回滚必须改go.mod的require行
临时覆盖模块版本：用 replace 替换远程路径
当需要测试本地修改、绕过代理、或强制统一某模块所有间接依赖的版本时，replace 是唯一可靠方式。它优先级高于 require，且对整个模块图生效。
replace github.com/some/lib => ./local-fork replace golang.org/x/net => golang.org/x/net v0.14.0
注意：replace 不会自动下载目标版本，需确保右侧路径存在且含有效 go.mod；若指向本地目录，该目录必须是 Git 仓库（含 .git），否则 go mod tidy 会报错 no module found。
-
replace仅在当前模块生效，子模块不会继承 - 上线前务必删除或注释掉开发用的
replace，否则构建环境可能找不到本地路径 - 用
go list -m all可查看最终解析出的模块版本，确认replace是否生效
升级/降级模块时，go get 的参数陷阱
go get 默认行为容易误导：不加 @ 会尝试升级到最新 minor 版（如从 v1.2.3 到 v1.9.0），加 @latest 反而可能跳到 v2.0.0（触发 major 版本迁移），而 @patch 并不存在。
真正可控的方式只有显式指定版本：
-
go get example.com/lib@v1.2.3→ 锁定该版本 -
go get example.com/lib@master→ 使用主分支 HEAD，生成伪版本，适合临时调试 -
go get -u=patch example.com/lib→ 仅升级 patch 级别（如v1.2.3→v1.2.4），但要求模块已发布对应 tag
最稳妥的做法始终是：先查清目标版本（go list -m -versions example.com/lib），再显式 go get @vX.Y.Z，避免任何隐式行为干扰。
模块版本看似只是字符串，但 go.mod 的每一行 require 都是构建确定性的基石；一旦写错格式、误信 go.sum 能锁版本、或滥用 replace 忘记清理，CI 构建就可能在某个凌晨突然失败。
