go list -m all 显示的是MVS算法实际选中的全局归一化版本，而go.mod中require仅声明最低版本要求；例如写v1.8.0但另一依赖要求v1.9.0时，MVS选v1.9.0并反映在go list -m all中，go.mod则保持原值直至go mod tidy更新。
为什么 go list -m all 显示的版本和 go.mod 里写的不一致
因为 go.mod 中的 require 行只是下限声明，不是锁定值；go list -m all 展示的是 MVS 算法实际选中的全局归一化版本。比如你写 require github.com/sirupsen/logrus v1.8.0，但另一个依赖要求 v1.9.0，MVS 就会选 v1.9.0 —— 这个结果会出现在 go list -m all 里，而你的 go.mod 仍保留 v1.8.0，直到你运行 go mod tidy 才可能被覆盖。
常见错误现象：改完 go.mod 直接编译，发现行为没变；或者 CI 构建失败，本地却正常——大概率是本地缓存了旧版本，而 MVS 实际生效版本已在别处被抬高。
go get github.com/x/y@v1.2.3 后版本反而降级了
这不是 bug，是 MVS 的必然结果：go get 触发的是全局重计算，不是单点覆盖。当你指定 @v1.2.3，MVS 会重新扫描整个依赖图，若其他模块只声明了 require github.com/x/y v1.0.0，且没有更高约束，那 v1.2.3 可能比当前图中已选的 v1.5.0 更“小”，于是它就成了新解——导致看似“降级”。
- 执行前先查谁在拉高版本：
go mod graph | grep x/y - 看所有可用版本：
go list -m -versions github.com/x/y - 确认是否真被锁死：
go list -m -u github.com/x/y（显示可升级提示）
replace 和 exclude 不是“修复”，而是显式绕过 MVS
replace 让 import 路径指向新目标，但不改变语义约束；exclude 则让 MVS 在计算时直接跳过某个版本。两者都会留下痕迹：
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
-
go list -m all中对应条目会出现// excluded或// indirect标记 -
replace指向本地路径时，CI 构建会失败（没那个目录） -
exclude github.com/bad/pkg v1.2.3后，如果有模块require github.com/bad/pkg v1.2.3，go build直接报错require github.com/bad/pkg: version "v1.2.3" excluded by //go.mod
真正安全的做法是先用 go mod edit -exclude=... 试跑，再检查 go.mod 是否新增了排除行，别靠肉眼编辑。
go mod tidy 为什么既升级又降级还删 require
go mod tidy 的本质是：读取全部 .go 文件里的 import → 收集直接依赖 → 递归解析每个依赖的 go.mod → 运行 MVS 得出唯一解 → 清理未被 import 的 require 行 → 同步更新 go.sum。
所以它可能：
- 升级：某间接依赖因新主依赖引入了更高
require，MVS 抬高版本 - 降级：某直接依赖被显式
go get @v1.2.3，MVS 回退全局解 - 删除：
require条目没被任何import引用，且没被其他模块依赖，就被清理
关键提醒：每次 go mod tidy 都可能动 go.mod 和 go.sum 两处文件，提交前务必 git diff 确认变更范围——尤其注意 // indirect 行的增减，那是 MVS 推导出的新约束，不是你手写的。
