Java record pattern 怎样匹配带泛型的记录组件

Java record pattern 匹配泛型记录时，要分清“记录的类型参数是否已知”和“组件值是否符合条件”。已知 Parcel 时可以显式写类型参数，也可以让编译器推断；来源只有 Object 时，不能靠记录模式凭空证明它是 Parcel。本文使用 Java 21 正式语法，不涉及基本类型模式的预览功能。

用静态类型约束解构模式

可以把这种写法理解为“静态约束下的解构”：方法签名负责表达容器契约，记录模式负责把组件绑定为局部变量。适合读取泛型响应、消息包装或嵌套数据记录。它减少临时变量，却不是一个新的反序列化器，也不负责修复上游失真的泛型声明。

例如业务方法接收 Parcel，相当于调用方已经承诺其中的组件类型。若所有入口都退化成 Object，再在深处尝试恢复泛型，阅读压力和错误处理反而会集中在解构代码里。应先设计入口类型，再选择简写。

写出显式与推断两种匹配

public class ParcelPatterns {
    record Parcel(T value) {} // 用记录保留组件声明

    static String explicit(Parcel source) {
        if (source instanceof Parcel(var text)) {
            return text == null ? "内容为空" : text.strip(); // 泛型类型已由参数确定
        }
        return "没有包裹"; // 外层记录为 null 时不匹配
    }

    static String inferred(Parcel source) {
        if (source instanceof Parcel(var text)) {
            return text == null ? "内容为空" : text.strip(); // 这里推断为 String
        }
        return "没有包裹";
    }
}

两种方法都把组件作为 String 使用。省略的是模式中的类型实参，并非把声明改成原始类型。判断点是 source 的静态类型，而不是某个样本刚好装了字符串。这里保留 null 分支，是因为容器存在不等于组件有值。代码为说明片段，未在本地执行，不附运行输出。

处理未知类型的记录组件

反例是把方法参数改成 Object 后，仍要求 Parcel(var text)。这种要求涉及未经检查的转换，编译器不能仅凭运行时的记录类身份确认类型实参。删除警告或先做强制转换，都不能补出缺失的证明。

如果业务只需要“包裹当前装着非空字符串”，可以匹配未知实参的记录，再判断实际组件。下面的方法应作为同一个类中的另一方法：

static String readUnknown(Object source) {
    if (source instanceof Parcel>(var value)
            && value instanceof String text) {
        return text.strip(); // 只接受本次组件值确实为字符串
    }
    return "不是字符串包裹"; // 包括外层为空、其他类型和组件为空
}

注意方法的承诺已经收窄：它证明的是本次 value 可以当作字符串用，并没有给原对象签发 Parcel 的泛型保证。若组件是 List，也不能只判断它属于 List 就相信每个元素都是字符串。需要逐项处理时，应在输入边界定义完整的数据转换规则，而不是给集合加一次未经检查的类型转换。

识别嵌套泛型与空值边界

static String nested(Parcel> source) {
    if (source instanceof Parcel(Parcel(var text))) {
        return text == null ? "内容为空" : text.strip(); // 嵌套参数提供推断上下文
    }
    return "包裹层缺失"; // 任一要被解构的记录为 null 都不匹配
}

嵌套模式适合结构本来就稳定的输入。两层包裹都有业务意义时，它把访问路径写得集中；如果还需要分别报告外层缺失和内层缺失，拆开判断会更清楚。不要为了缩短一行代码丢掉有用的错误分类。

空值需要区分位置：外层 null 无法被记录模式解构；内层记录 null 也无法匹配嵌套记录模式；最终的 var text 则可以接住 null，因此调用 strip 前仍需处理。匹配成功不能被解释为整个对象图都已非空。

确定采用范围并回答常见问题

采用前可以用三项判断：入口签名是否保留真实泛型；需要的是容器类型契约还是组件值筛选；不匹配时是否需要区分原因。前两项不清楚时，显式访问器和局部变量往往更容易维护。记录模式改善表达，不会自动提高输入数据的可信度。

省略类型实参就是原始类型吗？

不是。这里的记录模式支持类型推断；不要把它和方法形参直接写成原始 Parcel 混为一谈。优先保留参数声明中的泛型信息。

明明创建的是字符串包裹，为什么 Object 参数不能直接匹配？

某个创建点的事实不代表所有调用点都满足约束。方法应依赖可声明的契约；来源确实未知时，就匹配通配符记录并检查需要使用的组件。

要统一改成最短的嵌套写法吗？

不必。局部变量名称、错误分类和业务边界比行数更重要。简单读取可解构，复杂异常处理可分层保留。

技术规则参考：Oracle Java 21 记录模式；Oracle Java 26 泛型与嵌套记录模式。示例为围绕包裹读取场景编写的独立代码。