go get 不按指定版本执行是因 MVS 算法优先满足整个依赖树约束：v1 和 v2 路径互不感知，@v1.5.3 会被 require v2 的依赖静默忽略；真正锁定需用 go mod edit -require=... + go mod tidy。
go get 为什么总不按你写的版本来
执行 go get github.com/some/pkg@v1.5.3 后，go.mod 没变、实际加载的还是 v2.0.0，这不是命令失败，而是 MVS（最小版本选择）在生效：它优先满足整个依赖树的约束，不是执行“你点的菜”。
- 如果已有其他依赖 require
github.com/some/pkg/v2，那@v1.5.3请求会被静默忽略——v1 和 v2 是不同模块路径，互不感知 -
go get默认行为是“升级到满足所有约束的最低可行版本”，不是“锁定你指定的那个” - 若 tag 在 proxy 缓存中不存在，Go 会 fallback 到 latest 并只 warn，不报错，容易误判成功
想真正写入确切版本：用 go mod edit -require=github.com/some/pkg@v1.5.3，再运行 go mod tidy。这跳过 MVS 自动推导，强制落盘。
怎么确认项目里到底用了哪些版本
别靠肉眼扫 go.mod——间接依赖不会显式写在那里。真实加载版本以构建时解析结果为准：
-
go list -m all | grep somepkg：列出所有被选中的版本；重复出现即多版本共存 -
go mod graph | grep somepkg：看到谁、通过哪条路径拉进了哪个版本（例如github.com/a/tool github.com/some/pkg@v1.2.0） -
go mod why -m github.com/some/pkg@v1.5.0：追溯这个版本被哪个 import 触发，输出完整调用链
注意：go list -m -graph 输出太长，日常排查优先用 go mod graph + grep，比人工翻 go.mod 快得多。
立即学习“go语言免费学习笔记（深入）”；
replace 不是万能胶，用错反而埋雷
replace 是重写 import 解析路径的手术刀，但它不改变依赖树结构，也不阻止其他版本被间接引入。
- 适用场景：本地调试 patch、fork 修复未合入 upstream、私有镜像迁移
- 危险操作：用
replace github.com/old/pkg => github.com/old/pkg v2.0.0强制统一版本——如果你代码仍import "github.com/old/pkg"（v1 路径），它根本不会生效；必须同步改 import 到/v2 - 验证是否真生效：
go list -m all看输出里是不是显示=> ./local-fix或你指定的 fork 路径
上线前必须清理：replace 绕过 go.sum 校验，CI 构建若残留，可能因 GOPROXY 差异导致 panic。
多版本共存不是 bug，但得知道什么时候该管
Go 允许同一模块多个版本共存是设计特性，只要各模块 require 的版本满足语义化兼容规则（如 v1.2.0 和 v1.5.0），就能各自独立构建。只有当出现以下情况才需干预：
- 编译失败（undefined symbol、interface mismatch）
- 运行时 panic（比如某包内部函数签名在 v1.4.0 改了，但一个依赖按 v1.2.0 的 API 调用）
- 测试行为不一致（不同版本逻辑有差异，且被不同子模块触发）
真正容易被忽略的是：主模块 go.mod 中的 go 1.18 字段只控制语言特性和工具链行为（如泛型支持），完全不参与模块版本决策——版本走向只由 go list -m all 执行的 MVS 算法决定。
