@EventListener 和 Java 原生监听器虽然都基于“观察者模式”，但它们的应用层级、实现方式和灵活度有着本质的区别。简单来说，Java 原生监听器是底层的“接口实现”机制，而 Spring Boot 的 @EventListener 是基于注解的高级封装和框架级增强。

以下是两者的核心区别：

1. 实现方式与代码侵入性

• Java 原生监听器：通常需要实现特定的接口（如 ApplicationListener 接口，或 Java Web 中的 ServletContextListener、HttpSessionListener 等）。你需要重写固定的方法（如 onApplicationEvent），代码比较死板，侵入性较高。
• @EventListener：只需要在 Spring 容器管理的任意 Bean 的普通方法上加上注解即可。不需要实现任何接口，方法名可以随意起，代码非常简洁优雅，侵入性极低。

2. 功能与灵活性

• Java 原生监听器：功能相对单一。如果想监听多种不同类型的事件，通常需要实现多个接口或者在方法内部写大量的 if-else 进行手动判断。
• @EventListener：功能极其强大且灵活。
  • 多事件监听：一个方法可以直接监听多种事件（例如 @EventListener({事件A.class, 事件B.class})）。
  • 条件过滤：支持通过 SpEL 表达式进行细粒度的条件过滤（例如 @EventListener(condition = "#event.username.startsWith('admin')")），只有满足条件的事件才会触发该方法。
  • 链式发布：监听方法可以直接返回一个新的事件对象，Spring 会自动将其作为新事件继续发布。

3. 异步处理与事务结合

• Java 原生监听器：默认是同步阻塞执行的。如果需要异步，需要开发者自己手动去开启线程或配置线程池。
• @EventListener：与 Spring 生态无缝集成。
  • 异步支持：直接在方法上叠加 @Async 注解，就能让该监听逻辑在独立的线程中异步执行，极大提升主业务流程的响应速度。
  • 事务结合：提供了 @TransactionalEventListener 注解，可以精确控制监听器在事务的哪个阶段执行（如 AFTER_COMMIT 事务提交成功后才执行）。这能有效避免“主事务还没提交，监听器就去查库导致查不到数据”的经典问题。

核心区别对比总结

特性	Java 原生监听器 / ApplicationListener	Spring Boot @EventListener
实现方式	必须实现特定接口，重写固定方法	在任意方法上添加注解即可
代码侵入性	高（代码死板、繁琐）	低（灵活、优雅）
多事件监听	不方便（需手动判断或写多个类）	非常方便（注解内直接指定数组）
条件过滤	需在方法内手动写 if 逻辑	内置 SpEL 表达式支持（condition 属性）
异步支持	需手动配置线程池	直接叠加 @Async 注解
事务结合	难以精确控制事务阶段	支持 @TransactionalEventListener

总结与建议

• Java 原生监听器：更多是 Java 语言层面或传统 Java Web（如监听 Session 创建销毁、应用启动初始化）的基础设施机制。
• @EventListener：是 Spring 框架在业务开发层面的最佳实践。它让业务逻辑的解耦变得极其简单。

在现在的 Spring Boot 业务开发中，强烈推荐直接使用 @EventListener。它就像“快递柜”一样，你只需要把事件扔进去，监听器什么时候拿、怎么处理（同步还是异步），都可以非常灵活地配置，真正做到了业务模块的彻底解耦。

@TransactionalEventListener 是 Spring 框架提供的一个事务型事件监听器，它是普通 @EventListener 的增强版。

它的核心作用是：将事件监听器的执行时机，与数据库事务的生命周期精准绑定。

简单来说，普通的 @EventListener 在事件发布后会立即执行；而 @TransactionalEventListener 可以确保监听器里的代码，只有在事务真正提交成功后（或者回滚后）才会执行。

💡 为什么要用它？解决什么痛点？

在业务开发中，我们经常会遇到“主业务 + 附属业务”的场景。比如“用户注册”是主业务，“发送欢迎邮件”是附属业务。

如果不使用 @TransactionalEventListener，可能会遇到以下两个经典问题：

1. 数据不一致（异步抢跑）：主业务的事务还没提交，邮件监听器就已经开始执行了。如果监听器里需要去数据库查这个新用户的信息，会因为事务隔离性查不到数据，导致业务报错。
2. 事务回滚后的无效操作：主业务在执行过程中抛出异常，事务回滚了（比如用户根本没注册成功），但邮件监听器已经触发，导致用户没注册成功却收到了一封欢迎邮件。

@TransactionalEventListener 完美解决了这些问题，它能保证只有当用户数据稳稳地存入数据库后，才会去触发发邮件的操作。

💻 举个例子：订单创建成功后发短信

假设我们有一个创建订单的业务，需要在订单真正保存成功后，给用户发送一条短信通知。

第一步：定义一个订单创建事件

public class OrderCreatedEvent extends ApplicationEvent {
    private final String orderNo;
    private final String phone;

    public OrderCreatedEvent(Object source, String orderNo, String phone) {
        super(source);
        this.orderNo = orderNo;
        this.phone = phone;
    }

    public String getOrderNo() { return orderNo; }
    public String getPhone() { return phone; }
}

第二步：在带有事务的主业务中发布事件
注意，发布事件的方法必须带有 @Transactional 注解。

@Service
public class OrderService {
    @Autowired
    private ApplicationEventPublisher eventPublisher;

    @Transactional(rollbackFor = Exception.class)
    public void createOrder(String orderNo, String phone) {
        // 1. 执行核心的订单入库逻辑（数据库操作）
        System.out.println("正在保存订单到数据库...");
        // orderMapper.insert(order); 

        // 2. 发布订单创建事件
        // 此时事件虽然发布了，但使用了 @TransactionalEventListener 的监听器还不会立即执行
        eventPublisher.publishEvent(new OrderCreatedEvent(this, orderNo, phone));
        
        // 如果这里抛出异常，事务回滚，后续的短信监听器根本不会触发
    }
}

第三步：使用 @TransactionalEventListener 监听事件

@Component
public class SmsNotificationListener {

    // 核心注解：phase = AFTER_COMMIT 表示事务提交成功后才执行
    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    public void sendSmsAfterOrderCreated(OrderCreatedEvent event) {
        System.out.println("【事务已提交】正在给手机号 " + event.getPhone() + 
                           " 发送订单 " + event.getOrderNo() + " 的短信通知...");
        // 调用第三方短信接口发送短信
    }

    // 还可以监听事务回滚的情况，做补偿或记录日志
    @TransactionalEventListener(phase = TransactionPhase.AFTER_ROLLBACK)
    public void handleOrderCreationFailure(OrderCreatedEvent event) {
        System.out.println("【事务已回滚】订单 " + event.getOrderNo() + " 创建失败，记录告警日志。");
    }
}

⚙️ 核心参数说明

@TransactionalEventListener 提供了几个非常实用的属性：

• phase (事务阶段)：决定监听器在事务的哪个阶段执行，默认值是 AFTER_COMMIT。
  • BEFORE_COMMIT：事务提交前执行（适合做最后的校验）。
  • AFTER_COMMIT：事务提交成功后执行（最常用，确保数据已落库）。
  • AFTER_ROLLBACK：事务回滚后执行（适合做失败后的清理或告警）。
  • AFTER_COMPLETION：事务完成后执行（无论提交还是回滚都会执行，适合做收尾工作）。
• fallbackExecution (兜底执行)：默认为 false。如果发布事件的方法没有加 @Transactional 注解，监听器默认不会执行。如果设置为 true，则即使没有事务，监听器也会照常执行。
• 结合 @Async 使用：默认情况下，@TransactionalEventListener 是在主线程中同步执行的。如果发短信等附属业务比较耗时，可以在监听器方法上同时加上 @Async 注解，实现“事务提交后 + 异步执行”，进一步提升主接口的响应速度。