不能。Go Module 禁止同一构建中依赖同一模块路径的多个大版本（如 v1 和 v2），因 v2+ 必须通过带 /v2 后缀的 module path 导入，否则无法识别；强行共存会失败，且多数场景实为误判需求。
Go Module 能不能同时依赖同一个包的 v1 和 v2？
不能。Go 的 module 机制在设计上就禁止同一构建中加载同一个模块（module path）的多个大版本（major version > v0），比如 github.com/sirupsen/logrus 的 v1.9.3 和 v2.3.0。这不是限制，而是 Go 对语义化版本和导入兼容性的强制约定：v2+ 必须通过带 /v2 后缀的 module path 导入，否则根本无法被识别为“另一个模块”。
为什么 go get github.com/xxx@v2.0.0 不起作用？
因为没改 import path，Go 会直接忽略 v2+ 版本的请求，或者报错 unknown revision v2.0.0。v2+ 模块必须满足两个条件才能被正确拉取和使用：
- 模块作者已在
go.mod中声明module github.com/xxx/v2（注意末尾/v2） - 你的代码里 import 的路径也必须是
github.com/xxx/v2，而不是github.com/xxx - 你本地
go.mod中记录的依赖行也得是github.com/xxx/v2 v2.0.0
常见错误现象：执行 go get github.com/xxx@v2.0.0 后 go.mod 里还是 github.com/xxx v1.x.x，或者 build 报 import "github.com/xxx" is a program, not an importable package —— 都是因为路径没对齐。
如何让项目里同时用 logrus v1 和 logrus v2？
前提是 logrus 官方提供了 v2 模块（它没有）。但以真实支持多版本的库为例，比如 golang.org/x/net 或 google.golang.org/api，做法很明确：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 确认 v2 模块存在：查它的 GitHub 仓库根目录是否有
go.mod，内容是否为module golang.org/x/net/v2 - 在代码中分别 import：
"golang.org/x/net"和"golang.org/x/net/v2" - 运行
go get golang.org/x/net@latest和go get golang.org/x/net/v2@latest（注意路径含/v2） -
go.mod里会同时出现两行：golang.org/x/net v0.25.0和golang.org/x/net/v2 v2.0.0
性能与兼容性影响：两个路径被视为完全独立的模块，不共享任何符号，也不会冲突；但会略微增加 vendor 体积和 build 时间 —— 这是为兼容性付出的合理代价。
想绕过规则强行共存？别试了
有人试图用 replace、vendor、或 hack import path 来“骗过” Go toolchain，结果几乎都失败了：
-
replace只能映射到一个路径，不能让github.com/xxx和github.com/xxx/v2指向不同本地目录 - 手动改 import path（如
github.com/xxx/v2alpha）会导致第三方库无法识别，且破坏可重现构建 - vendor 也不能解决根本问题：vendor 目录里依然只能存一份
github.com/xxx的代码，v1/v2 冲突仍在
真正需要多大版本共存的场景极少；绝大多数情况其实是误判了需求 —— 比如以为要同时用 grpc-go 的 v1.33 和 v1.60，其实只需升级到 v1.60 并适配 API 变更。v1 和 v2 的割裂，本质是作者主动划清兼容边界，不是 Go 的 bug，也不是你需要绕开的障碍。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
