Java 25 原始类型模式怎么用：instanceof、switch 与预览特性验收

线上计费规则里经常混着整数、浮点数和未知输入：金额折扣可能是 int，比例可能是 double，外部配置还可能先以 Object 到达。Java 25 的 JEP 507 第三次预览让原始类型也能进入模式匹配，数值分支可以把“能否安全转换”和“转换后怎么处理”放到同一处检查。

Java 25 为什么要把原始类型放进模式匹配

旧代码处理一个 Object 数值时，常见写法是先用 instanceof 判断包装类，再取出值；如果输入来自已经确定类型的局部变量，又会退回到一串比较和强制转换。问题不在代码多几行，而在“数值范围”和“转换是否安全”很容易被藏在分支里，后续维护时漏改边界就会出问题。

JEP 507 把原始类型带进 instanceof、switch 和相关模式上下文。不过它在 Java SE 25 仍是预览特性，不能按普通语法直接当成长期兼容代码。先把版本边界写进构建脚本，再决定是否在业务模块使用。

先用 instanceof 验证安全的数值转换

下面的例子把一个未知对象交给折扣解析器。这里的重点不是把所有数字都转成 double，而是让模式表达“当前值可以安全视作哪一种类型”。

static String classify(Object value) {
    if (value instanceof int i) {
        return "整数折扣: " + i;
    }
    if (value instanceof double d) {
        return "小数折扣: " + d;
    }
    return "不接收的输入: " + value;
}

实际编译时，模式的可匹配关系由 Java 语言规范决定，不是任意两个数值类型都能互相匹配。尤其不要把“运行时会自动转型”理解成“模式一定可达”。先用小测试确认目标 JDK 的编译器行为，再把代码放进生产模块。

用 switch 和 when 表达数值区间

当规则从“是什么类型”进一步变成“落在哪个区间”，switch 的模式分支会比多层 if 更容易审阅。精确值放在前面，区间守卫放在后面，最后保留一个明确的兜底结果。

static String rating(double score) {
    return switch (score) {
        case 0d -> "未开始";
        case double v when v > 0d && v  "需要复核";
        case double v when v >= 2.5d && v  "基本通过";
        case 5d -> "满分";
        default -> "无效分值";
    };
}

when 后面的条件只负责收窄已经匹配到的模式变量。不要把范围判断和外部状态查询混在里面，否则分支虽然短，测试却会变得难以复现。NaN、正负无穷大也要在业务规则里明确归类，不能假设它们会自然落入普通区间。

预览开关和数值提升是上线前的两道门

可以先用一个最小文件验证工具链：

javac --enable-preview --release 25 -d out PatternRoute.java
java --enable-preview -cp out PatternRoute

编译和运行必须使用同一套预览开关。只在编译阶段打开，运行阶段会因为类文件依赖预览能力而失败；只在运行阶段打开，编译器又不会接受源代码中的预览语法。

数值提升也值得单独留一条测试。一个表达式经过提升后，可能已经不是你以为的原始类型；模式变量的类型、switch 选择器的类型和分支可达性要一起看。遇到编译器提示某个模式永远不可达时，优先检查提升和覆盖关系，不要靠调整分支顺序碰运气。

一组能留在项目里的验收测试

把下面几类输入放进参数化测试，能较早发现从 Java 24 预览代码迁移到 Java 25 时的行为变化：

• 整数、浮点数和包装类型分别进入 instanceof 分支，确认结果和日志类型一致。
• 区间下界、上界、刚好等于 0 和 5 的值分别测试，避免守卫条件重叠。
• Double.NaN、Double.POSITIVE_INFINITY 和负数走清晰的无效分支。
• null 输入有明确策略：单独判断，或在 switch 中显式处理。
• 去掉 --enable-preview 重跑一次，确认构建门禁确实能阻止误发布。

常见问题

Java 25 的原始类型模式是正式特性吗？

不是。Oracle 的 Java SE 25 语言变更文档将它列为预览特性，未来版本仍可能调整，因此应在构建、运行和升级说明中显式记录。

为什么编译器说某个 primitive pattern 不可达？

通常与选择器类型、数值提升或前面已经覆盖的模式有关。先缩小到一个最小示例，再检查类型转换规则和分支覆盖关系。

when 守卫里适合调用数据库或远程接口吗？

不适合。守卫应保持为可预测的值判断；外部副作用放到分支体内，并单独处理超时、重试和失败返回。

生产项目现在该不该使用这项语法？

如果项目能锁定 JDK 25、接受预览特性升级成本，可以在边界清晰的小模块试用；公共库和需要长期跨版本编译的模块应先保守评估。

把预览语法当成版本契约

原始类型模式解决的是表达力和类型安全之间的一段空白，但它的收益必须和预览特性的维护成本一起衡量。先用官方 JEP 和语言文档确认语义，再用统一的编译参数、边界数据和失败门禁做验证，最后才把它扩展到更大的业务分支。这样即使下一版 JDK 调整语法，迁移点也能被测试和构建配置准确指出。