Java模块化无法根治包名冲突，但能根治同名包被多模块导出引发的编译/启动冲突；通过模块边界隔离、导出唯一性校验、自动模块命名收敛三重机制截断冲突传播链。
Java 模块化项目中无法“彻底根治”包名冲突——因为包名冲突本身不是模块系统要解决的问题；真正能被根治的是同名包被多个模块导出所引发的编译期和启动期冲突。关键不在于包名是否重复，而在于模块是否允许导出相同包名、JVM是否允许加载。
模块系统如何切断包冲突的传播链
传统 classpath 下，只要两个 JAR 含有 com.example.utils.StringUtils，运行时就可能因加载顺序随机选一个，导致 NoClassDefFoundError 或 LinkageError。模块化后，这条链被三重机制硬性截断：
-
模块边界强制隔离：每个模块必须声明
exports才能让包对外可见；未导出的包，哪怕类是public，其他模块也完全不可见 -
导出唯一性校验：若 moduleA 和 moduleB 都在
module-info.java中写exports com.example.utils;，编译直接报错：error: package is declared in more than one module -
自动模块命名收敛：老 JAR 放入
--module-path后成为自动模块（如guava-32.0-jre.jar → 模块名 guava），它隐式导出所有包，但不允许其他显式模块再导出同名包；若你自己的模块也试图exports com.google.common.util，启动失败
真正需要你主动控制的三个关键点
模块系统只设防，不代劳。以下操作必须由开发者明确执行，否则隔离失效：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
禁止多模块导出同一包路径：业务模块（如
com.example.order）与工具模块（如com.example.common）必须严格划分包归属；绝不让两个模块都exports com.example.shared -
老 JAR 迁移时不滥用
--add-reads：自动模块默认可读所有模块，但若手动加--add-reads myapp/com.example.order=guava，再让另一个模块也读 guava，就可能触发包重导出警告 -
核心 API 包只由一个模块导出并版本锁定：例如统一由
com.example.api模块导出com.example.api.dto，其他模块仅requires com.example.api，不自行打包或复制该包下的任何类
包名本身仍需遵守工程规范
模块化不能替代包设计。即使启用 JPMS，以下习惯仍决定冲突是否发生：
立即学习“Java免费学习笔记（深入）”；
-
包名必须用反向域名风格（如
cn.yourorg.payment.sdk），避免util、common等泛化单层名——这类名字极易被多个依赖同时使用，一旦进入模块路径，立刻触发导出冲突 -
源码目录结构与
package声明严格一致：模块系统不校验这个，但编译器和 JVM 会拒绝加载路径错位的类，间接暴露包管理混乱 -
绝不把不同语义的类塞进同一个包：比如
com.example.user里既放 DTO 又放 Entity 还放 Mapper，未来拆模块时必然被迫拆包或导出冲突
当冲突真的出现：快速定位三步法
遇到 ResolutionException: Module X exports package Y to module Z and module W 时：
- 运行
java --list-modules | grep -i 关键词查看哪些模块含疑似包名 - 用
jdeps --list-deps your-app.jar找出哪些模块依赖了冲突包所在模块 - 检查各
module-info.java，确认只有一个模块写了exports com.xxx.yyy；其余模块应删掉该行，改用requires依赖提供方
