Go模块允许多版本共存是设计特性，但实际构建只选一个最低兼容版本（MVS），v1与v2因路径分隔可并存；go list -m all显示多版本仅反映声明约束，非运行时加载状态。
同一模块路径下不可能同时存在两个版本
Go 默认采用单一版本选择（SVS），不是“多版本共存”，而是“选一个最合适的”。go list -m all里看到 github.com/some/lib v1.2.0 和 github.com/some/lib v1.5.0 并不表示两者都被加载——只是说明它们被不同依赖声明了，最终只会保留一个版本参与构建。
真正能“共存”的只有两种情况：
- v2+ 路径分隔：比如
github.com/some/lib/v2和github.com/some/lib（即 v1）被视为完全独立的模块，可并存 - 主模块内嵌套多个
go.mod：如/cmd/a和/lib/b各自为模块，彼此 require 不同版本，但不会被同一个go build命令统一导入
其他所有“看起来多版本”的情况，都是 MVS 算法在后台做了裁决，你看到的只是输入约束，不是运行时状态。
最小版本选择（MVS）不是选最低，而是选最低兼容版本
MVS 的名字容易误导人。它不挑语义化版本号最小的那个，而是找满足全部 require 约束的、**最低的仍能通过构建的版本**。
例如：
- A 依赖
github.com/x/y v1.1.0 - B 依赖
github.com/x/y v1.3.2 - C 依赖
github.com/x/y v1.2.0
只要 v1.3.2 兼容 v1.1.0 和 v1.2.0（即没破坏性变更），MVS 就会选 v1.3.2 —— 因为更低的版本（如 v1.1.0）无法满足 B 的要求。
关键判断依据是主版本号是否一致：v1.x 和 v2.x 永远不兼容，此时 Go 不会尝试“选一个”，而是直接报错或启用路径分隔机制。
replace 和 exclude 都不解决根本冲突，只掩盖表象
replace 是路径重写，不是版本协调；exclude 是硬剔除，不是兼容适配。它们都不影响 MVS 的计算逻辑，只在 resolve 阶段干预 import 解析或拒绝某版本进入构建图。
常见陷阱包括：
- 用
replace github.com/x/y => ./fix后忘记go mod tidy，导致go.sum缺失校验和，CI 构建失败 - 对 v2+ 模块仅用
replace却没改 import 路径（仍写github.com/x/y而非github.com/x/y/v2），编译报import path doesn't match - 用
exclude github.com/x/y v1.5.0后，某个依赖要求>= v1.4.0且，结果无可用版本，go mod tidy直接失败
真正该做的，是用 go get github.com/x/y@v1.5.0 显式升级主模块的 require 行，再让 go mod tidy 重新跑 MVS。
go.mod 中的 go 指令控制编译器版本，不参与依赖选择
go 1.22 这行只干一件事：禁止用低于 1.22 的 Go 工具链构建该项目。它和模块版本无关，也不影响 go list -m all 或 go mod graph 的输出。
容易混淆的点：
- 你用
go1.23构建声明go 1.22的项目，完全合法 - 你用
go1.21构建声明go 1.22的项目，会立刻报错：go: cannot use go 1.21.x with go 1.22 mod -
go version和go env GOROOT必须对齐：手动设GOROOT反而会让多版本切换失效，新版 Go（1.17+）自动推导GOROOT，删掉所有显式设置更安全
依赖版本冲突和 Go 编译器版本冲突是两套独立机制，混在一起排查只会浪费时间。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
