EventListener 是 Java AWT/Swing 中的标记接口，无方法，其子接口（如ActionListener）才定义事件处理逻辑，需通过组件的addXXXListener()注册，不可直接实例化。
Java AWT/Swing 中的 EventListener 是接口不是类
很多人搜“Java EventListener 类库”，第一反应是找一个叫 EventListener 的可实例化类——但其实它只是 JDK 标准包里的一组**标记接口（marker interface）**，定义在 java.util 包中，本身不带任何方法。真正起作用的是它的子接口，比如 ActionListener、MouseListener、KeyListener 等。
这些接口都位于 java.awt.event（AWT）和 javax.swing.event（Swing）下，必须配合具体组件的 addXXXListener() 方法使用：
button.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
System.out.println("Button clicked");
}
});
- 不能直接
new EventListener()，编译会报错 - Swing 事件监听器大多继承自 AWT 接口，但部分扩展接口（如
TreeSelectionListener）只在javax.swing.event中 - Java 8+ 推荐用 Lambda 替代匿名内部类，前提是接口是函数式接口（如
ActionListener只有一个抽象方法）
JavaFX 的事件模型完全不同：用 EventHandler 而非 EventListener
JavaFX 不兼容 AWT/Swing 的监听器体系，它用的是泛型接口 EventHandler，所有事件类型都继承自 javafx.event.Event。这意味着你不会看到 MouseListener 这类名字，而是 MouseEvent、KeyEvent 等具体事件对象。
注册方式也更统一：
立即学习“Java免费学习笔记（深入）”；
基于Intranet/Internet 的Web下的办公自动化系统，采用了当今最先进的PHP技术，是综合大量用户的需求,经过充分的用户论证的基础上开发出来的，独特的即时信息、短信、电子邮件系统、完善的工作流、数据库安全备份等功能使得信息在企业内部传递效率极大提高，信息传递过程中耗费降到最低。办公人员得以从繁杂的日常办公事务处理中解放出来，参与更多的富于思考性和创造性的工作。系统力求突出体系结构简明
button.setOnAction(event -> System.out.println("FX button clicked"));
label.addEventHandler(MouseEvent.MOUSE_CLICKED, event -> { ... });
-
setOnXXX()（如setOnAction）用于单事件快捷绑定，覆盖默认行为 -
addEventHandler()支持多监听器、事件捕获/冒泡阶段控制（通过EventTarget和EventDispatchChain） - 不要混用 AWT/Swing 监听器到 JavaFX 组件上——它们运行在不同线程且事件循环隔离
第三方库如 RxJava 或 EventBus 不是“替代 EventListener”，而是重构事件流
像 RxJava、Guava EventBus、Spring ApplicationEvent 这些，并非 Swing/AWT/JFX 的监听器实现，而是提供**解耦的消息发布-订阅机制**。它们不依赖 UI 组件生命周期，也不受 EDT（Event Dispatch Thread）约束。
典型误用场景：
- 在 Swing 中用
EventBus.post(new DataLoadedEvent())替代firePropertyChange()—— 可行，但需手动保证线程安全（Swing 更新必须在 EDT） - 用
Observable.fromCallable(...).subscribeOn(Schedulers.io())处理耗时操作后更新 UI —— 必须显式切回SwingUtilities.invokeLater()或 JavaFX 的Platform.runLater() -
Guava EventBus默认不支持异步，要加AsyncEventBus才能避免阻塞发布线程
容易被忽略的线程与生命周期陷阱
最常导致崩溃或无响应的问题，往往不出现在监听器写法本身，而出现在执行上下文和对象存活期：
- Swing 监听器方法（如
actionPerformed）总在 EDT 执行；若在里面做网络请求或文件读写，整个 UI 会卡死 - 监听器持有外部对象引用（如匿名内部类引用了
this），可能阻止窗口关闭后内存释放（尤其JFrame没调dispose()） - JavaFX 中，如果在
initialize()里注册监听器，但对应控件是 FXML 动态加载且可能被替换（如BorderPane.setCenter()），旧监听器不会自动移除，造成重复触发 - 用 Lambda 写监听器时，若捕获局部变量，该变量必须是
final或“事实 final”；否则编译失败
复杂点在于：同一个事件，在不同 UI 工具包里代表完全不同的契约——不只是 API 名字不同，连线程模型、传播机制、内存管理规则都得重学一遍。
