很多 Spring Event 事故并不是事件机制本身“失效”，而是团队把进程内通知当成了可靠消息，又没有把它放回 Spring 生命周期里审视。真正需要建立的判断标准只有三个：事件发生在什么时候、失败后能否补偿、发布者是否必须知道订阅结果。三个问题没有答案之前，不要在核心链路里加 @EventListener。
问题不在注解，在运行边界
一个典型的 Spring Event 调用看起来很简单：发布者调用 ApplicationContext.publishEvent，Spring 根据事件类型匹配监听方法，监听器执行业务逻辑。开发阶段看到的是一条顺畅的调用链，线上系统面对的却是容器启动、滚动发布、流量摘除、线程池排空和进程退出。事件发布发生在这些边界上时，Bean 的可用性和业务入口的可用性可能已经不再一致。
服务关闭期间仍有请求进入，是最危险也最容易漏测的组合。Spring 在销毁 ApplicationContext 时会限制从 BeanFactory 获取 Bean；如果最后几个在途请求触发 publishEvent，框架为了寻找监听器而进行 Bean 查找，就可能抛出 destroy 阶段的异常。解决方式不是捕获这条异常然后假装成功，而是从部署流程上消除“关闭中的实例继续接流量”这个前提。
把优雅停机做成明确的状态机
建议把实例状态拆成 accepting、draining、stopped 三段。accepting 表示可以接收新请求和新消息；draining 表示服务发现和负载均衡不再把新流量送入，消费者暂停拉取，但已经开始的工作允许在预算时间内完成；stopped 才是关闭 Spring 上下文和基础设施。每次发布都应能在日志和监控中看到这三个状态，而不是只依赖 JVM 的退出日志。
- HTTP：先从网关或负载均衡摘除，保留连接排空时间。
- RPC：从注册中心下线，拒绝新请求，同时等待已进入线程池的调用完成。
- MQ：暂停拉取或停止消费，处理已获取的消息，按约定提交位点或进入重试。
- 定时任务：停止下一轮触发，避免停机尾部又创建新的业务工作。
启动也要反过来处理。监听器注册完成不代表数据库、缓存、远程客户端和消费者都可以接业务。让 Spring 完成刷新，在 SmartLifecycle 或 ContextRefreshedEvent 等明确的就绪节点之后开放入口，比在 init-method 里直接启动消费线程更可靠。启动时早到的消息必须有缓冲、暂停或重试策略，不能依赖“通常监听器已经注册了”。
同步、异步和 MQ 不是同一件事
Spring Event 默认更像应用内方法调用的抽象：监听器可以同步执行，异常可能回到发布者；加上 @Async 后，执行转移到线程池，发布者与监听结果分离，但队列容量、拒绝策略、线程池关闭和失败重试都需要另行负责。MQ 则提供持久化、跨进程消费、重试或死信等更重的能力。
选择时不要用“哪个更先进”来比较，而要看边界：同一 JVM 内的多个独立后处理动作，且事件丢失可以接受或由上游补偿，可以选 Spring Event；跨服务通知、实例重启不能丢、需要回放或需要隔离消费速度，应选 MQ；强一致主流程则应使用显式事务和状态编排。
用失败语义决定设计
强一致场景的关键是失败要改变主流程结果。提单时库存扣减失败，订单就不能成功；资源锁定失败，前面的动作应回滚或进入明确的补偿状态。把这些步骤拆成互不知情的监听器，会让发布者不知道谁失败、谁已经成功，也很难保持清晰的回滚顺序。
最终一致场景则相反：履约已经完成，结算通知暂时失败，不应让履约回滚。订阅者可以重试到成功，并在超过次数后写入故障表、发送告警，等待人工重放。Spring Event 很适合表达这种“主结果确认之后的本地分发”，前提是补偿机制不是口头承诺。
可靠性要落到四个工程部件
- 事件信封：包含 eventId、aggregateId、eventType、occurredAt 和 schemaVersion，方便追踪和兼容。
- 幂等存储：以 eventId 或业务键去重；外部副作用使用幂等请求号，数据库状态更新使用条件写。
- 失败通道：定义最大重试、指数退避、死信/故障表和人工重放入口，不能只在日志里打印堆栈。
- 可观测性：区分发布成功、监听开始、监听成功、监听失败和补偿完成，统计延迟与积压。
重试尤其容易制造假象：第一次执行已经扣款或写入，第二次又执行一遍。所有订阅者都要按照至少一次执行来设计，即便当前实现看上去只会调用一次。不要把“当前版本没有重复投递”当作幂等证明。
上线前的最小验证矩阵
- 应用完全启动前到达一条消息，验证它不会被静默丢弃。
- 发布过程中摘流后仍有在途请求，验证事件完成或进入可重试通道。
- 一个监听器成功、另一个监听器失败，验证状态和重试范围。
- 同一 eventId 投递两次，验证数据库和外部调用没有重复副作用。
- 线程池满载、下游超时、进程被强制终止，验证事件是否有明确的最终去向。
Spring Event 的正确定位很朴素：它是应用内解耦工具，不是可靠消息系统，也不是事务回滚引擎。把生命周期和失败语义补齐，它能让代码保持清晰；跳过这些前提，越“优雅”的注解越可能把故障藏到发布之后。