go.mod中require v1.2.0不等于实际使用该版本，MVS算法按最小满足原则选择v1.1.5；replace和exclude按序生效，主版本升级必须同步修改import路径和module声明。
go.mod里require写v1.2.0不等于用v1.2.0
你改完require github.com/foo/bar v1.2.0，go build跑起来却panic，查go list -m all发现实际加载的是v1.1.5——这不是bug，是MVS（Minimal Version Selection）算法的正常行为。
MVS只把require当“最低要求”，不是锁定指令。只要其他依赖（比如某个indirect包）只要求v1.1.0，而v1.1.5又满足所有约束、且比v1.2.0更小，它就会被选中。
-
go get github.com/foo/bar@v1.2.0会尝试升级，但若下游有更低约束，仍可能回落 -
go mod tidy后务必运行go list -m all | grep foo/bar确认真实版本 - 别信
go.mod里写的版本，也别信go get终端输出的“updated”提示
replace和exclude的生效优先级与陷阱
replace和exclude不是可选项，是覆盖规则：先exclude剔除版本，再replace重定向路径，最后才轮到require。
常见翻车点：
- 写了
replace github.com/x/y => ./local-fix但没运行go mod tidy，go.sum没更新，CI直接失败 - 用
exclude github.com/x/y v1.6.0后，某依赖要求>= v1.5.0且v1.6.0是唯一满足条件的版本，构建报no matching versions - 对主版本升级（如
v2）只replace却不改import路径（仍用github.com/x/y而非github.com/x/y/v2），编译报import path mismatch
@latest、@master、@commit这些修饰符怎么选
go get后面跟的修饰符决定版本解析起点，但最终仍受MVS裁决：
-
@latest：取最新**稳定版**（跳过v0.x和-beta/-rc），但不保证是MAJOR最新——v1.9.0可能比v2.0.0更“新”却不会选，因路径未带/v2 -
@master或@main：解析为伪版本（如v0.0.0-20260804123456-abcdef123456），绕过语义化约束，CI环境极易漂移 -
@e7a0c6（commit hash）：同样生成伪版本，适合临时调试，但go.sum校验严格，换环境需重新go mod download
生产环境严禁用@master或无标签commit；@latest仅用于工具类依赖（如golang.org/x/tools），业务依赖必须显式指定vX.Y.Z。
主版本升级为什么必须改import路径
Go不把v2.0.0当作v1.x的“升级”，而是视为**全新模块**。原因很简单：github.com/foo/bar和github.com/foo/bar/v2在导入时就是两个不同路径。
- 不改
import就直接go get github.com/foo/bar@v2.0.0，go build会报could not import github.com/foo/bar（找不到匹配的v2路径） -
go mod graph里能看到两个并存的节点：your/project github.com/foo/bar v1.5.0和your/project github.com/foo/bar/v2 v2.0.0 - 想统一升v2？得手动改所有
import "github.com/foo/bar"为"github.com/foo/bar/v2"，再go mod tidy
真正容易被忽略的，是v2+模块的go.mod里module声明也必须含/v2，否则go list -m all会显示路径错乱，后续replace也失效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
