go模块允许多版本共存，非错误；go list -m all 显示重复模块名仅说明不同依赖需不同版本，构建时各自加载互不干扰；真正问题表现为运行时报错或测试行为突变。
go list -m all 看到重复模块名就是多版本共存，不是错误
Go 模块系统本就允许同一模块多个版本共存，只要各依赖声明的版本满足语义化兼容规则（比如 v1.2.0 和 v1.5.0 都属 v1 主版本），构建时各自按需加载，互不干扰。你执行 go list -m all | grep github.com/sirupsen/logrus 看到两行输出，不代表项目坏了——它只是说明 pkgA 显式 require v1.8.1，而 pkgB require v1.9.3，Go 在编译时会为它们分别解析对应版本。
真正要警惕的是运行时报错：cannot use X as type Y、undefined: SomeFunc 或测试行为突变。这时才说明多版本触发了 API 不兼容，必须干预。
- 先确认是否真有冲突：跑一遍
go test ./...，尤其关注涉及该模块的 interface 实现或类型转换逻辑 -
go list -m -json all | jq -r 'select(.Path == "github.com/sirupsen/logrus") | .Version'只会输出一个版本——这是 MVS 最终选中的“主版本”，其他版本仅被间接依赖私有使用 - 如果
go.sum里出现同一模块多个校验和条目（如github.com/sirupsen/logrus v1.8.1 h1:...和github.com/sirupsen/logrus v1.9.3 h1:...），说明确实加载了多版本，但只要没报错，不用急着“统一”
用 replace 强制指定版本时，必须配 go mod tidy 才生效
replace 不是写进 go.mod 就立刻起作用的魔法开关。它只在构建时重写 import 路径解析，且仅对当前 module 有效。如果你只加了这一行：
replace github.com/sirupsen/logrus => github.com/sirupsen/logrus v1.9.3
但没运行 go mod tidy，go build 仍可能用缓存里的旧版，甚至报 invalid version: unknown revision（因为 v1.9.3 还没被拉进本地模块缓存）。
- 正确流程：改
go.mod→ 执行go get github.com/sirupsen/logrus@v1.9.3（触发下载+写入require行）→ 再go mod tidy清理冗余 -
replace路径必须严格匹配 import 路径：大小写、斜杠方向都不能错；github.com/Sirupsen/logrus和github.com/sirupsen/logrus是两个不同模块 - CI 构建失败？检查是否用了
replace ... => ./local/path—— 本地路径在 CI 环境里不存在，必须删掉或换成 git commit hash
exclude 比 replace 更激进，但只对明确已知的问题版本有效
当某个版本存在严重 bug（比如 golang.org/x/net v0.14.0 导致 HTTP/2 连接泄漏），且你无法控制上游依赖升级时，exclude 是唯一能彻底阻止它被选中的方式。它不像 replace 那样提供替代品，而是直接从整个依赖图中抹掉该版本。
写法很简单：
exclude golang.org/x/net v0.14.0
但它有硬性限制：只能排除别人 require 的版本，不能排除你自己 require 的版本；而且一旦排除，所有路径都不可再用这个版本——哪怕某个工具链强依赖它，也会直接失败。
- 先验证：用
go mod graph | grep 'golang.org/x/net@v0.14.0'确认它确实被某个间接依赖拉入 - 排除后必须
go mod tidy，否则go build仍可能因缓存尝试加载 - 慎用于主版本号不同的排除（如
exclude github.com/some/lib v2.0.0），这可能导致v1.x和v2.x混用，引发更严重的类型不匹配
go mod tidy 不是“修复命令”，它是 MVS 规则的忠实执行者
很多人以为 go mod tidy 是个“一键清理冲突”的按钮，结果发现它悄悄降级了你刚升级的 github.com/xxx 到旧版，然后一脸懵。这不是 bug，是 MVS 在工作：它必须选出一个满足所有依赖约束的最低可行版本。
比如你手动 go get github.com/xxx@v1.5.0，但某个子依赖 github.com/yyy 的 go.mod 里写死了 require github.com/xxx v1.2.0，go mod tidy 就会回退到 v1.2.0 —— 因为 v1.5.0 不满足 yyy 的约束。
- 查谁在压低版本：
go mod graph | grep 'github.com/xxx@'，看哪条边带@v1.2.0 - 想保住
v1.5.0？得让yyy升级，或者用replace绕过它的约束（前提是yyy兼容v1.5.0） - 盲目删
go.sum再go mod tidy会丢掉校验和，可能引入被篡改的包，生产环境禁止这么做
require 就 override 的。真正可控的操作只有三类——显式 require 提升主版本、replace 重定向解析、exclude 彻底剔除。其他都是徒劳。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
