promise链与事件驱动面向不同需求：前者适用于有明确依赖的线性业务流程，后者适用于跨模块松耦合的异步通信；实际项目中常主干用promise保证一致性，旁路用事件实现可扩展副作用。
Promise 链和事件驱动不是互斥的两种“架构”，而是面向不同协作粒度与控制流需求的设计思路：Promise 链聚焦于单个业务流程的线性编排与错误传递，事件驱动则强调跨模块、松耦合的异步通信与响应机制。选哪个不取决于谁更“高级”，而看你要解决的是“一个请求怎么串起来”还是“多个模块怎么不打招呼就协作上”。
Promise 链：适合有明确先后依赖的业务流水线
当你需要按顺序执行若干异步步骤（比如登录 → 拉用户信息 → 检查权限 → 跳转），且每一步的输出是下一步的输入，同时希望错误能自然冒泡、统一捕获，Promise 链就是最直接的选择。
- 每个
.then()返回新 Promise，天然支持扁平化串联，避免回调地狱 - 错误会穿透整条链，只要末尾加一个
.catch()就能兜住前面所有环节的 reject - 返回值自动包装、状态不可逆、语义清晰——它本质是声明式流程控制
- 不适合处理“多个无关操作并发后汇总”或“某动作触发多方响应”的场景
事件驱动：适合解耦、可扩展、多对多响应的系统结构
当不同模块之间没有直接调用关系，但又需要感知彼此状态变化时（比如：订单创建成功后，通知库存扣减、发短信、更新搜索索引），事件驱动就体现出优势。它不关心谁发、谁收，只靠事件名匹配。
- 发布者（如订单服务）只负责
dispatchEvent或emitter.emit('order.created', data)，完全不知道谁在监听 - 订阅者（如短信模块、库存模块）各自
addEventListener或emitter.on('order.created', handler)，互不影响 - 支持一对多、多对一、多对多；新增监听器无需改原有逻辑，扩展成本低
- 调试难度略高——流程不在线性代码里，需靠事件日志或调试工具追踪流向
实际项目中，两者常混合使用
一个典型组合是：用 Promise 链完成核心业务主干（如下单接口内部逻辑），再在关键节点主动抛出事件（如 emit('order.placed', order)），由其他模块监听并异步响应。这样既保证主流程可控可测，又让周边功能插拔自由。
- 主干用 Promise：确保原子性、一致性、错误集中处理
- 旁路用事件：实现审计、通知、缓存更新等非核心但必要的副作用
- NestJS、Electron、大型前端应用普遍采用这种分层策略
选型判断小结
如果问题形如“这三步必须依次执行，出错要回滚或提示”，优先 Promise 链；
如果问题形如“这个动作发生后，可能有七八个地方要反应，但我不能让它们互相知道”，那就该上事件驱动。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
