不存在“彻底解决”的通用方案，Go 的依赖冲突本质是 MVS 算法在满足所有约束下的必然结果；能做的，是精准干预、验证生效、避免掩盖问题。
不存在“彻底解决”的通用方案，Go 的依赖冲突本质是 MVS（最小版本选择）算法在满足所有约束下的必然结果；能做的，是精准干预、验证生效、避免掩盖问题。
为什么 go mod tidy 不能自动修复冲突
go mod tidy 只确保 go.mod 中声明的 require 是最小必要集合，它不升级、不降级已有依赖，也不解决互斥版本要求。比如：
- A 依赖
github.com/sirupsen/logrus v1.8.1，B 依赖github.com/sirupsen/logrus v2.0.0+incompatible，go mod tidy无法选出一个同时满足两者的版本，会直接报错inconsistent dependencies -
go.sum中出现同一模块多个校验和，说明历史拉取过不同版本，但tidy不会清理旧条目，只追加新条目 - 执行后仍报
cannot use ... as ... in argument，大概率是类型不匹配——MVS 选了低版本，而高版本 API 已变更
定位冲突源头必须用这三条命令
别猜谁在拉旧版，用命令看真实依赖图：
-
go list -m all | grep logrus：查当前实际选用的版本和来源路径 -
go mod graph | grep logrus：查谁直接require了哪个版本（输出形如myproj github.com/sirupsen/logrus@v1.8.1） -
go mod why -m github.com/sirupsen/logrus@v1.8.1：查完整调用链，例如# myproj<br>-> github.com/xxx/yyy<br>-> github.com/sirupsen/logrus
注意：go list -m -u all 只显示可升级项，不反映冲突原因；go mod vendor 后出问题，先 go mod verify 确认校验和一致，再检查 vendor/modules.txt 是否含预期版本。
立即学习“go语言免费学习笔记（深入）”；
replace 不是补丁，是临时接管路径
replace 生效的前提是：它必须覆盖所有 import 路径，并且不被其他 replace 嵌套抵消。常见失效场景：
- 写成
replace github.com/sirupsen/logrus => github.com/sirupsen/logrus v1.9.3，但某第三方库内部硬编码import "github.com/sirupsen/logrus/v2"，这个v2路径不受影响 - 本地路径
replace github.com/sirupsen/logrus => ../logrus-fix提交到主干，CI 构建失败（无该目录） - 两个
replace形成循环：A replace B，B replace A，Go 直接报错
验证是否真生效：go list -m github.com/sirupsen/logrus 输出应为 github.com/sirupsen/logrus v1.9.3，且 go mod graph 中对应边已重定向。
require + 版本写法决定 MVS 能否锁定
require 行的写法直接影响 MVS 是否尊重你的意图：
-
require github.com/sirupsen/logrus v1.9.3（完整语义化版本）→ 锁定，除非被更高优先级依赖强制覆盖 -
require github.com/sirupsen/logrus v1.9（省略 patch 号）→ MVS 可能选v1.9.5，只要存在且满足约束 -
require github.com/sirupsen/logrus v2.0.0+incompatible→ 主版本变更，与v1.x完全隔离，不会参与同一组 MVS 计算
线上项目务必写完整版本号；若需显式提升间接依赖优先级，go get github.com/sirupsen/logrus@v1.9.3 后手动删掉 // indirect 注释，使其成为直接依赖。
最易被忽略的一点：冲突常源于 GO111MODULE=off 或 GOPRIVATE 配置缺失导致私有模块解析失败，进而触发 fallback 到错误路径——先确认 go env GO111MODULE 是 on，再查 go list -m 是否成功返回模块名。
