模块设计阶段切断循环依赖更高效可靠，关键是从职责划分和依赖方向做根本约束：用分层契约代替双向引用，强制依赖单向流动，协同逻辑外移到编译期可验证的编排层，并以延迟绑定替代编译期强依赖。
模块设计阶段就切断循环依赖，比运行时补救更高效、更可靠。关键不是“怎么绕过”，而是从职责划分和依赖方向上做根本性约束。
用分层契约代替双向引用
两个模块不该互相知道对方的存在。比如订单模块和库存模块，不要让 OrderService 直接调用 StockService，也不要让 StockService 回调 OrderService。正确做法是：
- 定义统一事件接口（如 OrderPlacedEvent），放在独立的 domain-events 或 contracts 模块中
- 订单模块只负责发布事件，不关心谁消费
- 库存模块只订阅该事件，自行决定是否扣减、是否校验
- 两个模块都只依赖 contracts，彼此无 import 关系
强制依赖单向流动
在构建工具或代码规范层面堵住反向依赖路径：
- Maven 中通过 enforcer 插件 配置 dependencyConvergence 和 banDuplicateClasses，禁止模块 A 引入 B 的同时，B 又引入 A
- Java 包结构按层级命名：com.example.order、com.example.stock、com.example.shared，CI 流程中用 ArchUnit 断言 “order 不得 import stock”
- IDEA 中启用 “Package Dependencies” 分析图，每次提交前自动生成依赖快照，发现环立即告警
把协同逻辑外移到编排层
真正产生循环感的地方，往往是多个模块共同参与一个业务流程（如下单→扣库存→发通知→更新积分）。这时应主动拆出一层：
- 新增 order-orchestration 模块，它引用 order、stock、notify、points 等所有下游模块
- 该模块不写业务规则，只做顺序调度和错误回滚（例如：调用库存失败则触发订单取消）
- 原模块退化为纯能力提供者（StockService 只负责扣/查/回滚，不决定“什么时候扣”）
- 所有跨模块调用都变成 orchestration → [具体模块]，再无横向直连
用延迟绑定替代编译期强依赖
某些场景下，模块间确实需要交互，但不必在类加载时就绑定死：
- 用 ServiceLoader 或 Spring 的 @ConditionalOnMissingBean 实现策略可插拔，避免硬编码 new 或 @Autowired
- 关键服务接口定义在 shared 模块，实现类放在各自业务模块，运行时由容器注入
- 对非核心路径（如日志扩展、审计钩子），采用 回调函数 或 Consumer
参数传入，调用方不持有被调用方类型
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
