Spring ApplicationEvent 实现本地异步解耦，核心是事务提交后发布轻量自定义事件，监听器加 @Async 异步执行，支持多监听器横向拆分、失败隔离。
用 Spring 的 ApplicationEvent 实现本地业务异步解耦，核心是把耗时、非关键路径的逻辑从主流程中剥离出来，靠事件触发 + 异步执行完成解耦。它不依赖 MQ，轻量、零额外中间件，适合单体或模块内解耦。
定义清晰的自定义事件类
事件是数据载体，要聚焦“发生了什么”和“需要带哪些上下文”。继承 ApplicationEvent，用不可变字段封装必要信息，避免在监听器里查库或拼参数。
- 事件源（
source）一般传this或ApplicationContext，不建议传业务实体（易引发循环依赖或序列化问题） - 只放 ID、状态码、简单枚举等轻量字段，比如
orderId、status、operatorId - 加
@Data和@ToString提升可读性和调试效率
发布事件要快、准、稳
在主业务逻辑提交成功后（如数据库事务已 commit），调用 ApplicationEventPublisher#publishEvent()。别在事务未提交前发，否则监听器可能查不到最新数据。
- 推荐注入
ApplicationEventPublisher，而不是直接用ApplicationContext—— 更语义明确、利于测试 - 不要在事件对象里塞大对象（如完整订单 VO），会增大内存开销和 GC 压力
- 如果需统一管理发布入口，可封装
EventUtil.pushSynEvent()工具类，但注意静态方法无法被 Spring AOP 拦截
监听器默认同步，必须显式转异步
Spring 默认所有监听器同步执行，主线程会卡住直到全部处理完。要真正解耦，必须让监听逻辑异步跑。
- 最常用方式：在
@EventListener方法上加@Async，前提是启动类有@EnableAsync，且配置好线程池 - 替代方案：监听器内部手动提交到自定义线程池（如
taskExecutor.submit(() -> {...})），更可控但代码略冗余 - 避免全局改为异步广播器（
SimpleApplicationEventMulticaster.setTaskExecutor()），会影响所有事件，包括框架内置事件（如 ContextRefreshedEvent），风险高
按场景合理设计监听粒度
一个事件可以有多个监听器，各司其职，实现横向拆分。
- 用户注册成功事件 → 发短信监听器、发邮件监听器、初始化积分监听器、写操作日志监听器
- 订单支付完成事件 → 扣减库存监听器、触发履约监听器、更新推荐权重监听器、推送埋点监听器
- 监听器之间无调用关系，互不影响；某个失败不影响其他，便于定位和补偿
