旧的java.awt.Font可以方便地进行序列化 - 但是有点烦人的是，JavaFX 字体类不是。更烦人的是，手动序列化很尴尬，因为构造函数中指定的FontPosture和FontWeight对象在构造后不可用（不得不求助于调用和解析getStyle()。）我正在努力思考为什么会这样，表面上在至少我当然看不到 AWT 字体上不存在的 JavaFX 字体上存在的任何功能，这些功能很难序列化。
是否有任何技术原因导致我错过了这种情况，或者它是否是 API 异常，可能会在未来的版本中得到纠正？
我怀疑这与通常在版本之间不兼容的可序列化类有关。如果应用程序依赖于可序列化的 UI，您可能会在版本之间遇到一些重大问题。您可以在 swing 组件上看到有关使用序列化的警告。
警告：此类的序列化对象将与未来的 Swing 版本不兼容。当前的序列化支持适用于运行相同版本 Swing 的应用程序之间的短期存储或 RMI。从 1.4 开始，java.beans 包中添加了对所有 JavaBeansTM 长期存储的支持。请参阅 XMLEncoder。
话虽如此，我也会在这里发表我的意见。对我来说，序列化 UI 会混淆 MVC 分离（当然还有其他架构 - MVC 不是金子弹）。把你关心的东西放在一个单独的对象中似乎更简单；您已经编写了执行 UI 的代码 - 如果它需要位于特定的 x/y 坐标，或者对象应该专注于启动，那么只保存该信息而不是每个默认颜色是有意义的，侦听器, 与节点关联的皮肤。
您可能有不同的需求-根据您的问题，我不知道。如果您正在寻找一种从文件加载 UI 的方法（而不关心保存），我建议您研究 FXML 和 CSS（不过我假设您已经知道这些事情）
JavaFX 中很少有东西是序列化的。您可以通过查看javadoc的序列化表单页面找出所有可序列化的内容。有了它，您可以看到几乎唯一可以序列化的东西是基于旧的可序列化java.util.EventObject和与 Swing 集成的 JFXPanel 的事件。其他一切都不可序列化。因此，在几乎没有其他东西的情况下，Font 可序列化是非常不典型的。
JavaFX 本身在很大程度上依赖于它的动态属性机制及其关联的绑定和更改侦听器。底层属性系统本身（当前）是不可序列化的，所以这就是 JavaFX 没有大量序列化的原因之一。
也就是说，Font 对象在 JavaFX 中很少见，因为它似乎是不可变的，只提供了构造函数和 getter 方法，没有使用任何属性。所以理论上它可以很容易地序列化。您可以提出提出此建议的功能请求。虽然它可能被视为低优先级，因为 JavaFX 本身并不真正依赖序列化。JavaFX 实现中的序列化方法似乎是不序列化，除非需要与现有 API 或框架集成。
如果您对 JavaFX 中的序列化以及框架没有大量使用它的原因还有其他问题，您可以在openjfx-dev 邮件列表中提问。我的猜测是（类似于尼克在他的回答中发布的警告），由于多种原因，框架中的全面序列化支持被认为是一个坏主意，因此故意决定不支持它（但这只是一个猜测）。