Go依赖版本由MVS算法自动选择满足所有约束的最低兼容版本，require声明下限而非锁定版本；go mod tidy重算依赖图并更新go.mod/go.sum；replace和exclude显式干预MVS；go.sum仅校验完整性，不锁定版本。
go.mod 中的 require 是怎么选版本的？
Go 不是简单取最新版，而是用「最小版本选择（MVS）」算法：在满足所有依赖约束的前提下，选每个模块能用的最低兼容版本。比如 github.com/gorilla/mux 被 A 依赖 v1.8.0、被 B 依赖 v1.9.0，最终会选 v1.9.0；但如果 B 只要求 >= v1.7.0，而 A 明确锁死 v1.8.0，那 Go 就选 v1.8.0 —— 它够用，且最保守。
这种机制让依赖树更稳定，但也容易让人误以为“没升级就是落后”。实际中：
-
go get -u会尝试升到最新兼容版，但不跨主版本（v1不会自动升到v2） -
go get package@v2.0.0才会强制切主版本，前提是模块路径含/v2 - 如果某个依赖间接拉入了多个次版本（如
v1.10.0和v1.12.0），MVS 会统一升到v1.12.0，但不会跳到v2
为什么 v2+ 版本必须改 import 路径？
Go 模块把主版本号当作路径的一部分，不是语义标签。比如 github.com/sirupsen/logrus 的 v2 版本，正确 import 路径是 github.com/sirupsen/logrus/v2，否则 Go 会当成 v1 处理，甚至报错 unknown revision v2.0.0。
这不是约定，是硬性规则。原因很直接：
立即学习“go语言免费学习笔记（深入）”；
- 不同主版本被视为完全独立的模块，避免 API 不兼容导致静默崩溃
-
go.sum里记录的是完整路径 + 版本，logrus/v2和logrus的哈希值互不干扰 - 如果你手动在
go.mod里写require github.com/sirupsen/logrus v2.0.0却没改 import，go build会失败
go.sum 文件到底要不要提交？
要，而且必须提交到 Git。它不是缓存文件，而是构建一致性的最后一道防线。
go.sum 记录的是每个依赖模块及其 .mod 文件的 SHA256 哈希值。它的作用不是“防止下载篡改”，而是“防止本地意外修改”。常见误解：
- 关掉
GOSUMDB=off并不能绕过校验，只是跳过官方 checksum 数据库比对，本地go.sum仍会被严格检查 - 私有模块或离线环境里，
go.sum是唯一能验证依赖是否被替换成非预期版本的依据 - 如果团队有人删了
go.sum再go mod tidy，可能拉到不同 commit 的伪版本（如v0.0.0-20250101-abcd123），导致构建结果不一致
伪版本（pseudo-version）什么时候会出现？
当你依赖一个没打 Git tag 的 commit 时，Go 自动生成伪版本，格式为 v0.0.0-YEARMONTHDAY-HOURMINUTESEC-COMMIT，例如 v0.0.0-20260715142301-8f3a1b2c3d4e。
这很常见，但容易埋坑：
- 伪版本不遵循 SemVer，
go get -u不会自动升级它——因为“最新”无法定义 - 如果上游后来打了
v1.2.0tag，你得手动执行go get package@v1.2.0才能切换过去 - CI 构建时若网络抖动导致某次拉到不同 commit，伪版本就变了，
go.sum校验失败
真正麻烦的不是伪版本本身，而是没人定期清理它们。上线前最好跑一遍 go list -m -u all，看看哪些依赖还卡在伪版本上。
