spring applicationevent 机制提供解耦骨架，需设计意图+正确配置：事件建模聚焦业务语义、不可变轻量；发布与监听职责分离，事务后发布；异步需替换广播器并配@async；加强可观测性与容错。
Spring 的 ApplicationEvent 机制不是“开箱即用就解耦”，而是提供了解耦的骨架——真正实现模块间松耦合，关键在于设计意图+正确配置，尤其要打破“默认同步”的认知陷阱。
事件建模：聚焦业务语义，不带实现细节
定义事件时，只封装核心业务上下文，不掺杂技术逻辑或处理路径。比如订单创建完成，事件应是 OrderCreatedEvent，只含 order 实体或必要 ID、时间戳；不要包含“是否发邮件”“要不要记日志”这类决策信息。
- 继承
ApplicationEvent（兼容老版本）或直接使用普通 POJO（Spring 4.2+ 支持）均可，重点是不可变、轻量、语义清晰 - 事件源（
source）通常传this或服务 Bean，用于调试溯源，不参与业务判断 - 避免在事件中传递复杂对象图或未序列化类型（如 Hibernate 代理），防止监听器反序列化失败或 N+1 查询
发布与监听：明确职责边界，禁止跨层调用
核心服务只负责“做完自己的事 + 发一个干净事件”，绝不调用任何辅助模块的方法；监听器只响应事件、执行本职动作，不反向修改主业务状态。
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 发布方（如
OrderService）在事务提交后（或显式控制传播行为）调用publishEvent()，确保事件携带的是已持久化的数据 - 监听器方法用
@EventListener标注，支持泛型匹配（@EventListener(OrderCreatedEvent.class)），也支持 SpEL 条件过滤（如@EventListener(condition = "#event.order.amount > 100")） - 监听器 Bean 必须由 Spring 容器管理（
@Component），否则不会被广播器发现
异步解耦：必须替换广播器，不能只加 @Async
默认 SimpleApplicationEventMulticaster 是同步执行，监听器跑在主线程和同一事务里——这根本不算解耦，只是把调用藏在注解后面。真异步需两步到位：
- 声明自定义
ApplicationEventMulticasterBean，绑定生产级线程池（非SimpleAsyncTaskExecutor） - 监听器方法上加
@Async，且满足：所在类是 Spring 管理 Bean、方法非private/static、不通过this直接调用（避免绕过代理） - 若监听器涉及数据库操作，注意事务传播行为（如
@Transactional(propagation = Propagation.REQUIRES_NEW)），避免被主事务回滚影响
可观测性与容错：解耦不等于甩手不管
异步事件丢失或失败不易察觉，需主动加固：
- 关键监听器（如发短信、扣库存）建议记录事件处理日志，含事件 ID、时间、结果，便于追踪补偿
- 对第三方调用（HTTP、MQ）做超时和重试（如
@Retryable），避免单点故障拖垮整个事件链 - 可引入简单本地事件表 + 定时任务，对长时间未完成的事件做状态核对与人工干预
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
