Go模块依赖版本解析依靠Minimal Version Selection（MVS）算法，该算法在满足所有依赖约束的前提下，选择语义化版本规则下版本号数值最小的可行版本；主版本不同（如v1与v2）被视为独立模块，需显式修改导入路径（如加/v2后缀）；伪版本用于未打tag的提交，格式为v0.0.0-yyyymmdd-hhmmss-commithash，仅限调试；go.sum校验模块zip包的SHA256哈希值以确保内容与go.mod记录完全一致。
Go模块依赖版本解析靠什么算法
Go不靠人工指定“用哪个版本”，而是用 Minimal Version Selection（MVS）自动算出满足所有依赖约束的最低兼容版本。这不是“选最小的数字”，而是“在语义化版本规则下，选能同时满足所有require条件的、版本号数值最小的那个”。
比如项目直接 require github.com/gorilla/mux v1.8.0，而它依赖的 golang.org/x/net 是 v0.17.0；另一个间接依赖又 require golang.org/x/net v0.18.0。MVS会选 v0.18.0 —— 因为 v0.17.0 不满足后者约束，而 v0.18.0 是满足两者且版本号最小的可行解。
- MVS只在相同主版本内比较（
v1.x.y和v2.x.y视为完全独立模块） - 它不关心“谁先声明”，只看约束集合是否可解
-
go list -m all显示的是最终解析结果，不是原始 require 列表
主版本号不同为什么会被当成两个模块
Go强制要求：当依赖主版本升级（如从 v1.9.0 到 v2.0.0），模块路径必须显式包含 /v2 后缀，例如 github.com/some/lib/v2。否则 go mod tidy 会报错 invalid version: malformed version。
这是语义化版本的硬性约定，不是Go自己发明的规则——它直接复用 SemVer 规范。主版本变更意味着不兼容API改动，Go不允许“悄悄覆盖”，必须让导入路径和模块路径都体现差异。
立即学习“go语言免费学习笔记（深入）”；
- 没加
/v2的v2.0.0版本会被拒绝写入go.mod - 即使你手动改
go.mod强行写入，go build也会失败并提示路径不匹配 - 同一项目里可以同时存在
github.com/some/lib（v1）和github.com/some/lib/v2（v2），它们互不影响
伪版本（pseudo-version）是怎么生成和使用的
当你 go get 一个还没打 Git tag 的提交时，Go会生成伪版本，格式是 v0.0.0-yyyymmdd-hhmmss-commithash（如 v0.0.0-20260715-142301-abcdef123456）。它不是真实语义版本，但能唯一标识某次 commit。
伪版本只用于开发调试或临时引用，不适合发布到生产环境。它的存在说明：这个依赖还没走正式发布流程。
- 伪版本优先级低于真实 SemVer（如
v1.2.3比v0.0.0-...更受信任） -
go mod tidy会把伪版本“升级”成最近的真实 tag（如果存在） - CI/CD 流程中应禁止伪版本出现在最终
go.mod中，可用go list -m -json all | jq -r '.Version' | grep '^-'检查
go.sum 文件到底校验什么
go.sum 不是校验“模块是否被篡改”，而是校验“模块内容是否与 go.mod 中记录的版本完全一致”。每一行形如：github.com/gorilla/mux v1.8.0 h1:/OZKzLqY...，其中哈希值是该模块 zip 包的 SHA256。
只要有人动过 go.mod 里的版本号，或者模块作者重新打包了同名同版 zip（哪怕只是重压缩），哈希就会变，go build 就会失败并提示 checksum mismatch。
-
go mod download -dirty可临时跳过校验（仅调试用） - 私有模块若未配置
GOPROXY，go.sum仍生效，但需确保本地 fetch 到的内容与远程一致 - 删除
go.sum后运行go mod tidy会重新生成，但前提是网络可达且模块未被撤回
go.sum 的联动：一次 go get 引入伪版本后，如果后续该模块打了正式 tag，go mod tidy 会自动替换版本号并更新 go.sum —— 但团队成员若没同步 go.mod 和 go.sum，构建就可能在某台机器上突然失败。 
