Spring ApplicationContext事件监听机制基于观察者模式，通过事件发布-监听实现业务与辅助逻辑解耦；事件需继承ApplicationEvent并封装关键数据；用ApplicationEventPublisher发布，@EventListener注解监听最常用。
Spring 的 ApplicationContext 事件监听机制本质是观察者模式的落地，它让业务模块之间不直接调用，而是通过“发消息—收消息”的方式协作。核心在于：发布者只管发事件，不关心谁处理；监听器只管响应事件，不参与主流程。这样就能把登录、下单、预约这类主逻辑，和发短信、写日志、更新缓存等辅助逻辑彻底分开。
定义清晰的事件载体
事件是通信的“信封”，要能准确表达发生了什么、附带哪些数据。推荐继承 ApplicationEvent，并把业务关键字段封装进去：
- 事件类必须有构造方法，传入 source（事件来源对象） 和业务数据，比如订单ID、用户手机号
- 字段尽量精简，避免暴露无关细节；如需复杂数据，可封装成 DTO 对象作为属性
- 从 Spring 4.2 起支持直接发布普通 POJO，框架会自动包装为 PayloadApplicationEvent，但显式继承 ApplicationEvent 更利于类型安全和 IDE 提示
用 ApplicationEventPublisher 发布事件
发布动作应嵌在主业务完成之后，且与监听逻辑完全隔离。获取发布器最常用方式是依赖注入：
- 在 Service 或 Controller 中 @Autowired ApplicationEventPublisher publisher
- 调用 publisher.publishEvent(new XxxEvent(this, data)) 即可，无需手动管理监听器列表
- 注意：publishEvent 是同步调用，默认阻塞主流程；若监听逻辑耗时（如调外部接口），建议后续加 @Async 支持异步执行
监听器实现方式灵活选择
监听器负责响应事件，Spring 提供两种主流写法，按场景选用：
立即学习“Java免费学习笔记（深入）”；
- @EventListener 注解方式（推荐）：轻量、简洁，支持泛型推导和条件过滤（如 @EventListener(condition = "#event.status == 'SUCCESS'")）
- 实现 ApplicationListener 接口：适合需要复用或统一处理逻辑的场景，例如所有事件都先记录审计日志再分发
- 监听器类需加 @Component，确保被 Spring 扫描注册；监听器之间无执行顺序保证，如需顺序控制，得自行加锁或队列
利用内置事件做系统级解耦
除了自定义业务事件，ApplicationContext 自带的生命周期事件也能用于解耦系统行为：
- ContextRefreshedEvent：容器初始化完毕后触发，适合预热缓存、加载配置
- ContextClosedEvent：容器关闭前触发，可用于释放资源、清理临时文件
- 这些事件无需手动发布，监听即可，天然规避了在启动/关闭代码中硬编码各种初始化逻辑
