go不允许同一模块路径下多版本共存，因为模块路径（如github.com/sirupsen/logrus）即包身份，版本仅为快照；go build和go list按路径解析import，由mvs算法选定唯一满足所有依赖的最低兼容版本，仅v2+路径分隔（如/v2）或主模块内嵌套子模块才被官方支持为“多版本共存”合法场景。
Go 为什么不允许同一模块路径下多版本共存
Go 的 go build 和 go list 在解析 import 路径时，只认模块路径（如 github.com/sirupsen/logrus），不带版本号；而版本信息仅由 go.mod 中的 require 指令决定。这意味着：只要两个依赖都 import github.com/sirupsen/logrus，无论它们各自 require 的是 v1.8.0 还是 v1.14.0，Go 都会强制选一个版本——通常是满足所有依赖的最低公共版本（minimal version selection）。这不是 bug，而是设计选择：模块路径即包身份，版本只是它的快照。
真正能“多版本共存”的两种合法场景
所谓“多版本共存”，实际是指多个模块路径被 Go 视为不同实体，从而允许各自独立版本。只有以下两种方式被官方支持：
-
v2+ 路径分隔：模块发布 v2.0.0 时，必须在
go.mod中将模块路径显式升级为github.com/sirupsen/logrus/v2；此时import "github.com/sirupsen/logrus"和import "github.com/sirupsen/logrus/v2"是两个完全无关的包，可同时存在于构建中 -
主模块内嵌套子模块：比如项目根目录有
go.mod，同时cmd/legacy目录下也有自己的go.mod；只要cmd/legacy不被main包直接 import，它的依赖版本就不会参与顶层构建的版本选择
常见误判：vendor 或 replace 并不等于多版本共存
很多人看到 go mod vendor 后 vendor/ 下同时存在 logrus@v1.8.0 和 logrus@v1.14.0 的文件夹，就以为“版本共存了”。其实这只是文件系统层面的复制，go build 仍只使用 go.mod 中选定的那个版本。同理，replace 只是把某个模块路径映射到本地路径或另一版本，它不创造新模块路径，也不绕过单一版本选择规则。
典型错误现象：import "github.com/sirupsen/logrus" 在代码里写了两次，一次来自 A 依赖，一次来自 B 依赖，但最终编译时只用一个版本——哪怕你手动 go get github.com/sirupsen/logrus@v1.8.0 和 go get github.com/sirupsen/logrus@v1.14.0，go.mod 也只会保留其中一个 require 行。
如何验证当前构建实际使用的版本
别信 go list -m all 输出的全部行，那只是模块图展开结果；要确认真正参与编译的是哪个版本，用：
go list -f '{{.Path}} {{.Version}}' github.com/sirupsen/logrus
这个命令返回的才是当前构建中该路径对应的最终解析版本。如果想看它是被谁拉进来的，加 -deps：
go list -deps -f '{{if .Module}}{{.Module.Path}} {{.Module.Version}}{{end}}' github.com/sirupsen/logrus | grep logrus
注意：输出中若出现 github.com/sirupsen/logrus/v2，说明它和 github.com/sirupsen/logrus 是隔离的；若只出现一次 github.com/sirupsen/logrus，不管 go.mod 里写了几行 require，都证明 Go 已完成版本合并。
最易忽略的一点：模块路径是否含 /v2、/v3 等后缀，不是看 GitHub tag 名，而是看该模块 go.mod 文件第一行声明的 module 字段值——这才是 Go 解析 import 时唯一认的“身份证”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
