模块化重构关键在于借 module-info.java 倒逼结构清理：先禁 exports 暴露耦合点，再按调用方向精准导出，最后用 opens/uses/provides 替代硬依赖，聚焦接口抽象与依赖注入以消除循环。
直接在旧代码里加 module-info.java 很容易触发循环依赖报错，尤其当模块边界模糊、包混用严重时。关键不是“加模块”，而是借模块化倒逼结构清理——把隐式耦合显性暴露出来，再逐层解耦。
先识别真实循环链，别只看 requires
Java 编译器报 module cycles 时，往往不只是两个 requires 互相指。真正的问题常藏在：
- 未导出的包被其他模块通过反射或类加载器强行访问（比如
Class.forName("x.y.Z")） - 某个模块导出了本该私有的工具类，结果被多个模块反向依赖
- 自动模块（如老 JAR 包）被多个具名模块 require，又间接反向引用了具名模块里的类
- 服务加载机制（
uses/provides）形成隐式双向绑定
分阶段重构：从“可编译”到“真解耦”
不追求一步到位，按三步走：
-
第一阶段：补 module-info.java 但禁止 exports
每个旧模块先写最简
module-info.java，只声明模块名和requires java.base，所有exports先注释掉。这样能强制暴露哪些包被外部直接引用——编译失败的位置就是耦合点。 -
第二阶段：按调用方向收敛 exports
查看谁在用你的包（IDE 的 “Find Usages” 或
jdeps --multi-release 17 --list-deps），只对真正被依赖的包做exports；内部实现包一律不导出，哪怕暂时编译不过，也要用接口/抽象类替代直接引用。 -
第三阶段：用 opens / uses / provides 替代硬依赖
若必须支持反射或 SPI 场景，改用
opens com.example.internal to com.config.loader替代导出整个包；用uses com.example.spi.ConfigReader+provides实现方，切断具体实现类的依赖链。
处理变量级耦合：聚焦字段与构造器
旧代码里常见字段类型跨模块引用（如 private OrderService orderService; 在 A 模块，而 OrderService 在 B 模块），这时：
- 把
OrderService提取为接口，放到公共 API 模块（如com.example.api），A 和 B 都只依赖这个接口模块 - A 模块的构造器参数改为接口类型，B 模块提供实现，并通过
provides声明 - 避免在字段声明中直接 new 实例或静态引用——这类变量是循环依赖的温床，一律转为依赖注入或工厂获取
验证是否真正解耦
完成重构后，用这几条快速检查：
- 执行
javac --module-path mods -d out --module-source-path src $(find src -name "module-info.java")，应无 cycle 错误 - 运行
jdeps --require java.logging --module-path mods --modules your.module.name，输出依赖图中不应出现闭环箭头 - 删掉某个模块的
exports行，如果其他模块立刻编译失败，说明还有隐式强依赖没切干净
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
