Spring Event 上线前，先过这张生命周期与可靠性验收表

在 Spring 项目里，最值得警惕的不是“有没有用 Spring Event”，而是团队是否知道每个事件丢失、重复和延迟之后会发生什么。事件发布本身只是一瞬间的调用，真正决定方案质量的是上下文生命周期、入口治理、业务一致性和重试幂等。

一个事件到底承诺了什么

Spring Event 通常用来把一个应用内的动作通知给多个监听者。发布者不必直接依赖每个订阅者，新增通知、缓存刷新或结算同步时，也不必持续扩大主流程的方法体。这种解耦很有价值，但它只解耦了代码依赖，并没有自动提供持久化、跨进程传输、消费位点、死信和回放。

因此设计事件前必须写出它的承诺：事件允许丢吗？允许重复吗？发布者必须等待吗？监听器失败会改变主业务结果吗？如果这些问题的答案不同，技术方案也应该不同。

关闭阶段的隐性竞态

服务滚动升级时，进程收到退出信号并不代表请求瞬间消失。连接复用、网关缓存、RPC 在途调用、MQ 已拉取消息和定时任务都可能在短时间内继续执行。此时发布事件，Spring 可能需要从正在销毁的 ApplicationContext 查找监听器，触发 BeanFactory 在 destroy 方法中被请求的异常。

治理顺序应当是：先阻断新入口，再等待在途工作，再关闭业务线程和连接，最后关闭上下文。这个顺序同样适用于启动：先让 Bean、连接和监听器完成初始化，再开放入口。把“应用启动完成”和“实例进程存在”分成两个状态，才能避免早到消息和晚到请求。

事件与事务边界必须对齐

库存、支付、提单、优惠券锁定等需要强一致的动作，应在显式的服务方法和事务边界内完成。失败时由主流程决定回滚、拒绝或补偿，不能把关键步骤藏进一组互不知情的事件监听器。即使可以通过复杂配置把异常重新抛回去，也会引入顺序、部分成功和回滚责任不清的问题。

相反，主交易已经成功后的结算通知、索引刷新、报表更新、缓存清理，通常属于最终一致动作。它们失败后可以重试，必要时转入故障队列，不必让已经确认的主结果回滚。Spring Event 在这种场景下能有效减少应用内分发代码。

可靠性不是加一个 @Retryable

重试只是可靠性的一部分。真正完整的方案至少需要：

• 稳定的事件身份：eventId 与业务主键分开，既能追踪一次事件，也能识别同一业务对象。
• 幂等处理：去重表、唯一约束、条件更新和幂等外部 API，至少使用其中一种可证明的机制。
• 有界重试：最大次数、退避和异常分类明确，避免对不可恢复错误反复撞击下游。
• 人工接管：超过自动边界后进入故障记录，提供可审计的重放和结果确认。
• 关闭可恢复：进程退出时未完成的工作必须留在 MQ、Outbox 或数据库待处理状态，而不能只留在线程内存里。

对于同步监听器，发布方法可能感知到订阅异常；对于异步监听器，异常不会自然回到原调用栈，线程池和错误处理器就成为可靠性边界。对跨服务事件，直接采用 MQ 或 Outbox 通常比在 Spring Event 外面再拼一层补偿更容易审计。

一张简单的决策表

把验收写进发布流程

上线前至少演练一次启动早到消息、关闭阶段在途请求、监听器部分失败、重复投递、线程池耗尽和下游长时间不可用。检查的不是“有没有抛异常”，而是事件最后去了哪里、业务状态是否可解释、重试是否会制造重复副作用。

Spring 官方对事件监听器的定位是清楚的：它提供应用上下文中的事件发布与监听能力。工程团队需要补上的，是消息可靠性和生命周期治理。知道边界之后，Spring Event 仍然是一个好工具；不知道边界，它就会在最不适合的地方承担最不该承担的责任。需要核对框架行为时，以 Spring 官方事件文档为准；停机异常的复现背景见 掘金案例。