JS模块拆分遇循环依赖，用事件通信替代import是否为合理解决方案？

这种基于发布订阅模式的事件通信方案是解决跨模块循环依赖的正规且广泛使用的合理方案，绝非掩盖问题的丑陋hack。

核心逻辑 #

循环依赖的本质是模块导入链路形成闭环，导致模块初始化或函数调用时出现未定义异常。你将直接import调用改为事件触发的方式，本质是把两个模块的直接强依赖，转换为双方同时依赖第三方事件调度中心的弱依赖，直接打破了导入链路的闭环，从根源上解决了循环依赖问题，本身就是经典的软件解耦设计思路。

这种模式在工业界已经被大量验证：浏览器DOM事件、Node.js内置EventEmitter、前端框架的全局事件总线、微服务架构的事件驱动通信，底层都是相同的逻辑。

适用场景判断 #

当出现以下情况时非常推荐使用该方案：

• 两个模块属于完全不同的功能域，比如示例中的业务逻辑模块和交互提示模块，本身就不应该存在强依赖
• 强行重构合并模块会破坏代码的内聚性，导致单个文件职责过重、维护成本升高
• 需要一对多的通知场景，同一个事件需要触发多个不同模块的逻辑

使用注意事项 #

为了避免后期维护成本上升，使用时需要遵守几个规范：

• 统一管理事件名：建议将所有事件名抽离到单独的常量文件，比如export const EVENT_SAY_HI = 'sayHi'，事件触发方和监听方都引用同一个常量，避免拼写错误
• 明确参数契约：提前约定事件传递的参数结构、类型，使用TypeScript的话可以给全局事件添加类型声明，避免参数传递错误
• 做好事件清理：在长运行进程或单页应用中，不再需要的事件监听要及时销毁，避免内存泄漏
• 不要过度使用：如果两个模块本身内聚性极高，合并后更符合代码逻辑，就不要为了拆分强行使用事件方案；也不要把所有函数调用都替换为事件触发，否则会导致项目调用链路不透明，排查问题难度大幅提升

可选替代方案 #

如果你的场景是一对一的调用，也可以考虑依赖注入方案，比如将sayHi作为参数传入demo函数，同样可以规避循环依赖，你可以根据自己的业务场景选择更合适的方案。

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