Maven传递依赖冲突时能否引入多版本同依赖供不同上层依赖调用

能不能同时引入不同版本的C让A、B各用各的，完全取决于你使用的编程语言生态和包管理器，不同场景下支持度差异很大：

支持多版本共存的常见场景 #

• JavaScript/Node.js生态（npm/yarn/pnpm）：原生支持嵌套依赖，只要A、B声明的C版本范围不兼容，包管理器会自动将对应版本的C安装在A、B各自的node_modules目录下，二者完全隔离，无需额外配置就能实现各用各的版本。
• Java生态：可以通过maven-shade-plugin等构建插件做shade操作，将其中一个依赖的C包重命名，修改类路径前缀实现隔离，比如将B依赖的C 2.0重命名为com.example.shaded.c后，B就会自动调用重命名后的版本，和A依赖的原版C 1.0互不干扰。
• Go生态（Go 1.11+）：支持不同主版本的模块同时导入，如果C的两个版本主版本号不同（比如v1.x和v2.x），可以直接同时引入，A、B各自声明对应版本即可直接使用。
• Rust生态（Cargo）：默认支持多版本依赖共存，只要两个C的语义化版本号不兼容，Cargo会自动编译多个版本的C，分别链接给A、B使用。

不支持多版本共存的常见场景 #

• C/C++生态：绝大多数场景无法直接共存，编译后的静态/动态库符号没有命名空间隔离，同时链接两个版本的C会直接出现符号冲突，运行时报错。除非手动修改其中一个版本C的所有符号前缀做隔离，或者通过dlopen系列函数在不同代码路径按需加载不同版本的动态库。
• Python生态（pip/setuptools）：默认不支持多版本共存，site-packages目录下同个包只能存在一个版本，同时声明两个版本的C会直接触发pip的版本冲突报错。只能通过virtualenv等环境隔离方案拆分项目，或者手动修改其中一个依赖的源码调整依赖适配。
• PHP生态（Composer）：默认同个包只能安装一个版本，会自动选择满足所有依赖声明的兼容版本，找不到兼容版本就会直接报错，只能通过第三方插件手动做命名空间前缀隔离才能实现多版本共存。

通用处理建议 #

• 优先查询你所用包管理器的官方规则，确认是否原生支持多版本传递依赖共存，原生支持的场景不需要额外操作，包管理器会自动处理。
• 如果原生不支持，优先尝试升级A或者B到支持同一版本C的新版本，这是最稳妥的方案，不会引入额外的兼容性风险。
• 实在找不到兼容版本的情况下，再考虑使用shade、重命名命名空间之类的隔离方案，这类方案会增加构建复杂度，也可能引入未知的运行时问题。

内容的提问来源于stack exchange，提问作者iluvex