go.mod 中的 require 行记录直接依赖的最小满足版本，由最小版本选择（MVS）算法确定，而非手动指定版本；真正锁定内容的是 go.sum 的哈希值，而非 require 文字。
go.mod 中的 require 行到底记录什么版本
require 行只记录直接依赖及其**最小满足版本**，不是“你手动敲的版本”本身。Go 使用「最小版本选择（MVS）」算法，在所有依赖约束下挑出能同时满足所有要求的最低兼容版本。比如 A 依赖 github.com/foo/bar v1.3.0，B 依赖 github.com/foo/bar v1.5.0，go.mod 中最终写入的会是 v1.5.0——因为这是两者都能接受的最低版本，而非你 go get 时指定的那个。
常见误解是：改了 require 行就等于锁死了该版本。其实不然：go mod tidy 会重算整个依赖图并覆盖它；go build 也会按需校验和升级间接依赖。真正起锁定作用的是 go.sum 中的哈希值，而不是 require 的文字。
- 直接依赖可显式指定，如
go get github.com/sirupsen/logrus@v1.9.3 - 间接依赖（即依赖的依赖）由 MVS 自动推导，不建议手动编辑
require去硬写它们 - 若某间接依赖被多个路径引入、版本不一致，Go 会选一个统一版本，不会共存
为什么 v2+ 版本必须带 /v2 路径后缀
Go 不把 github.com/user/lib v2.0.0 当作新版本，而是当作**破坏性变更警告**——除非模块路径本身包含 /v2。这是因为 Go 将模块路径（module path）作为唯一标识符，github.com/user/lib 和 github.com/user/lib/v2 在 Go 看来是两个完全不同的模块。
没加 /v2 却发了 v2.0.0 tag，会导致下游项目 go get 时行为异常：要么拒绝升级（因主版本跃迁未声明），要么错误地复用 v1 的路径导致编译失败或运行时 panic。
立即学习“go语言免费学习笔记（深入）”；
- 发布 v2 必须同步修改
go.mod第一行：从module github.com/user/lib改为module github.com/user/lib/v2 - import 语句也必须同步改成
import "github.com/user/lib/v2" - 旧 v1 用户不受影响，新 v2 用户无法意外降级到 v1 —— 这才是语义化版本在 Go 里的落地方式
go.sum 不是 lock 文件，但比 lock 更关键
go.sum 记录的是每个模块 zip 包内容的 SHA256 校验和，每次 go build 或 go test 都会核对。它不控制版本选择，但控制**包内容是否可信**。删掉 go.sum 或设 GOSUMDB=off，会让构建跳过校验，等同于关闭防篡改机制。
容易踩的坑：
- CI 流程中执行
go mod download后再提交生成的go.sum—— 这会让本地go build因校验失败而中断，因为go.sum应由开发者本地运行go mod tidy后提交 - Git 忽略
go.sum—— 它必须进仓库，否则不同机器拉代码后可能拉到不同 commit 的同一 tag，导致行为不一致 - 手动编辑
go.sum—— 格式敏感且易出错，应始终由 Go 工具自动生成
replace 和 exclude 的真实适用场景
replace 是开发期临时打补丁的手段，不是长期方案；exclude 是紧急规避严重 bug 的兜底操作，用完就得删。两者都会绕过 Go 的版本解析逻辑，一旦滥用，go list -m all 显示的依赖树就不再反映真实构建图。
典型误用：
- 用
replace指向本地目录后忘了在 CI 中还原，导致构建失败 - 用
exclude删除某个间接依赖，结果发现另一个依赖其实强依赖它，构建直接报missing module - 以为
replace能解决主版本冲突——它只能替换路径，不能让 v1 和 v2 共存；真要共存，得靠路径分隔（/v2）
复杂点在于：replace/exclude 的效果只对当前模块生效，子模块若单独 go build，这些规则不继承。这意味着多模块项目里，每个 go.mod 都得单独维护替换规则。
