Java嵌套Record解构必须显式声明内层字段，如WindowFrame(Point origin, Size size)，禁止省略为WindowFrame(Point, Size)；编译器通过字段级绑定实现null安全检查与路径推导。
嵌套 Record 解构时，为什么直接写 instanceof WindowFrame(Point, Size) 会编译失败
因为 Java 不允许在模式中省略嵌套 Record 的字段声明 —— 即使你只关心外层结构，也必须显式写出内层字段的解构形式。比如 WindowFrame(Point origin, Size size) 是合法的，但 WindowFrame(Point, Size) 会被拒，编译器报错 error: illegal pattern。
真正起作用的是「字段级绑定」：只有当你明确写出 Point(int x, int y) 或 Size(int width, int height) 这类带类型+变量名（或 var）的子模式时，编译器才能推导出字段访问路径并生成安全的 null 检查。
- 必须为每个嵌套 Record 提供完整字段模式，哪怕只用其中一两个字段
- 支持
var简写，但不能跳过字段声明本身 - 若某嵌套字段可能为
null（如size字段未初始化），模式匹配会自动跳过该分支，无需手动判空
switch 中嵌套 Record 匹配：如何避免 case 分支爆炸
面对继承自同一 sealed interface 的多个嵌套 Record 类型（例如 Order 下有 OnlineOrder(Address, PaymentMethod) 和 InStoreOrder(StoreLocation, CashPayment)），别把所有组合都拆成独立 case。优先用「类型守卫 + 嵌套解构」合并逻辑。
比如你想提取所有订单的收货城市，不管线上还是线下：
switch (order) {
case OnlineOrder(Address(String city, String street), var payment) -> System.out.println("City: " + city);
case InStoreOrder(StoreLocation(String city, int zip), var payment) -> System.out.println("City: " + city);
default -> System.out.println("Unknown order type");
}
- 两个
case共享city提取逻辑，避免重复代码 -
var payment表示忽略具体支付类型，不参与匹配也不绑定变量 - 如果某个
case需要额外条件（如仅处理信用卡支付），加when子句即可：case OnlineOrder(..., CreditCard(String cardNo)) when cardNo.startsWith("4") -> ...
嵌套解构中的 null 安全性：它到底帮你挡了哪些坑
Record 模式匹配对嵌套字段的 null 检查是「隐式且不可绕过」的。比如 WindowFrame(Point origin, Size size) 中，只要 size 为 null，整个 instanceof 判断就为 false，不会抛 NullPointerException，也不会进入分支体。
- 你不需要写
wf.size() != null && wf.size().height() > 0这类前置判断 - 但要注意：这种保护只作用于 Record 字段本身；如果字段是普通 class（非 record），其内部字段仍需手动判空
- 若想让 null 字段也能匹配（比如允许
size == null时走默认逻辑），得改用类型模式 + 显式判空，Record 模式本身不提供「可选字段」语法
性能与字节码：嵌套模式匹配真比手写 getter + 判空快吗
编译后，JVM 会将 instanceof WindowFrame(Point(int x, int y), Size(int w, int h)) 编译为一次类型检查 + 多次字段读取指令，和你手写 if (o instanceof WindowFrame) { ... wf.origin().x() ... } 几乎等价 —— 没有运行时反射、没有额外对象创建。
- 优势不在执行速度，而在「编译期校验」：字段名写错、类型不匹配、record 被修改后字段顺序变化，都会在编译时报错，而不是运行时
NoSuchMethodException - 嵌套越深，模式匹配的可维护性优势越明显；三层以上嵌套时，手写判空+getter 很容易漏掉某一层的 null 检查
- 注意：不要在循环体内频繁做深层嵌套匹配（如遍历 List<WindowFrame> 并每次匹配
Size的height），虽然单次开销小，但语义上不如先解构再复用变量清晰
