JavaFX凭借GPU加速、SceneGraph统一管理和帧同步线程模型，在动画、高刷、3D和WebView等场景显著优于Swing；Swing依赖CPU软渲染、缺乏内置异步抽象且布局维护成本高，适合简单界面或JDK≤8的老旧环境。
JavaFX 和 Swing 的底层渲染机制差异直接影响动画和高刷体验
JavaFX 默认启用 GPU 硬件加速，所有节点（Node）都通过 SceneGraph 统一管理，动画、缩放、透明度变化走的是原生图形管线；Swing 则完全依赖 CPU 软渲染，靠 RepaintManager 触发双缓冲绘制，复杂动画容易掉帧或卡顿。
- 实测：一个 60fps 的旋转 3D 柱状图，JavaFX 在中端笔记本上稳定运行；Swing 即使用
Timer+BufferStrategy手动优化，也很难维持 30fps 以上 - 坑点：
SwingUtilities.invokeLater()不能替代 JavaFX 的Platform.runLater()—— 后者绑定到渲染帧周期，前者只保证在 EDT 执行，不保帧率 - 兼容性注意：JavaFX 在某些 Linux 发行版（如 Ubuntu Wayland 默认会话）下需加 JVM 参数
-Dprism.order=sw强制回退到软件渲染，否则WebView或透明窗口可能黑屏
FXML + CSS vs 手写布局代码：界面维护成本差距明显
JavaFX 允许用 FXML 描述 UI 结构，配合外部 styles.css 控制样式；Swing 没有等效标准方案，GroupLayout 或 GridBagLayout 写出来就是一堆嵌套参数，改个边距都要重算权重。
- 典型场景：调整按钮圆角和悬停色。JavaFX 只需改 CSS 中的
-fx-background-radius和:hover伪类；Swing 得重写ButtonUI子类或依赖第三方 LookAndFeel（如 Substance），且不同 JDK 版本行为可能不一致 - 坑点：
FXMLLoader.load()抛NullPointerException多半是 controller 类没加@FXML注解，或fx:controller路径写错——它不会报“类找不到”，而是静默失败 - 性能影响：大量动态生成的 Swing 组件（如千行
JTable）比 JavaFX 的TableView更吃内存，因后者支持虚拟滚动（cell recycling），前者默认全加载进内存
线程模型决定你该怎么写耗时操作
JavaFX 强制要求 UI 更新必须在 JavaFX Application Thread 执行，但提供了 Task + Service 封装后台逻辑；Swing 虽然也要求 EDT 更新，但缺乏内置异步抽象，容易写出 SwingWorker 套娃或直接 new Thread() 导致 IllegalStateException。
- 正确姿势：JavaFX 中用
Task包裹数据库查询，task.valueProperty().addListener()绑定结果到Label.textProperty()；Swing 得手动在done()里调SwingUtilities.invokeLater() - 常见错误：
Platform.runLater(() -> { /* 更新 UI */ });里调用了阻塞 IO（如FileInputStream.read()）——这会卡住整个渲染线程，界面瞬间冻结 - 注意：JavaFX 的
ObservableList是线程不安全的，从后台线程往里 add 元素仍会抛异常，必须用Platform.runLater()包裹
模块化（Java 9+）让 JavaFX 依赖更清晰，但 Swing 依然“开箱即用”
JavaFX 自 Java 11 起不再捆绑 JDK，必须显式声明模块依赖；Swing 仍在 java.desktop 模块里，只要用 JDK 8+ 就能直接 new JFrame。
