Java 编程面试：原始类型模式如何改变 instanceof 与 switch？
题干与适用场景
团队评估 Java 25 中用于 instanceof、switch 和 record pattern 的原始类型模式预览特性。解析器得到 Number 值，需要分类整数和浮点数，同时不能发生隐式缩窄或 null 崩溃。请解释语言规则，给出小例子，并说明兼容性与发布决策。
JEP 507 在 Java 25 中仍是预览特性。强回答必须说明编译和运行需要预览开关，生产不能把它当成自动稳定的语言契约。
面试官考察点
- 是否区分引用模式、原始类型模式和装箱转换。
- 是否能解释安全扩宽、不安全缩窄与信息丢失。
- 是否明确处理
null、NaN和无穷大。 - 是否理解穷尽式 switch 与预览兼容边界。
- 是否能设计稳定回退与测试，而不是只因代码更短就采用。
面试官要听到规则和反例，不是 JEP 编号清单。
回答前需要澄清的问题
- CI 和生产是否允许预览特性？若不允许，必须使用 Java 21 时代的模式或显式转换。
- “分类数值”要保留原值，还是允许得到有界整数？这决定缩窄是否能成立。
null应拒绝、映射为UNKNOWN，还是由专门分支处理？NaN和无穷大是否为合法输入？类型匹配不会把它们自动变成普通有限值。- 同一源码是否必须在非预览 JDK 上编译？若必须，隔离预览代码或保留稳定实现。
30 秒回答框架
“Java 25 的 JEP 507 预览版允许模式在原始类型场景中表达更统一的匹配，过去需要装箱或复杂守卫。编译器只允许符合规则的安全转换，并拒绝可能丢失信息的缩窄。我会先处理可空引用，再测试边界值、NaN 和无穷大，并把预览开关固定在工具链里。若部署不能固定 Java 25 和预览开关，就用稳定的 switch 或显式范围校验。”
分步骤深入解答
1. 先确认值的静态类型
模式兼容性不代表任意数值都能转换为任意原始类型。Number 引用可能实际持有 Integer、Long、Double 或其他实现。先匹配包装类型再拆箱，与对原始选择器使用原始模式，是不同契约。讨论穷举前先说清选择器类型和转换方向。
static String classify(Number value) {
if (value == null) {
return "missing";
}
return switch (value) {
case Integer i -> "int:" + i;
case Long l -> "long:" + l;
case Double d when Double.isNaN(d) -> "nan";
case Double d -> "double:" + d;
default -> "other";
};
}这个稳定示例匹配包装类型，并没有声称所有 Number 都能安全缩窄为 int。
2. 解释扩宽与缩窄
JEP 507 统一原始模式规则，使模式变量在转换安全时可以接收原始值。int 扩宽到 long 保留全部值；long 缩窄到 int 可能丢失高位，因此不能允许静默接受。回答应指出被拒绝的转换，并在业务确实需要缩窄时提出显式范围检查。
static String bucket(long value) {
if (value >= Integer.MIN_VALUE && value <= Integer.MAX_VALUE) {
int narrowed = (int) value;
return "small:" + narrowed;
}
return "wide:" + value;
}这里的强转有可见不变量。模式不能代替这个证明。
3. 把 null 与原始匹配分开
原始值不能是 null，但包装选择器可以。引用选择器的 switch 不会把 null 默认为数值分支。需要完整结果时加入 case null，否则在进入 switch 前拒绝。不要用 default 掩盖 null 或未知包装类型，因为二者的运维处理不同。
浮点类型匹配也不代表有限值。若下游依赖排序或算术，必须显式检查 NaN、正无穷和负无穷。
4. 有意构造完整 switch
原始模式和常量能让 switch 更短，但覆盖范围仍取决于选择器和守卫。带守卫的分支不能覆盖该类型全部值。要用无守卫分支或 default 处理剩余值，并为可空选择器加入 case null。计费、解析或安全策略使用的结果必须可观测，不能静默吞掉未知值。
5. 检查预览边界
JEP 507 在 Java 25 中是预览特性，编译和运行需要匹配的 --enable-preview，源码级别也必须和 JDK 一致。后续 JDK 可能改变或删除预览语法。CI 应同时编译稳定回退版本，产物记录 JDK、预览开关和语言级别。公共库也不应强迫调用者为一个 API 开启预览。
6. 比较替代方案
异构 Number 输入且重视兼容性时，使用包装类型模式。选择器已经是原始类型且部署能固定预览工具链时，才考虑原始 switch。业务规则是“必须落入 32 位”时，显式范围检查更能表达意图，也不依赖语法变化。代码更短不代表数值契约更安全。
高质量示范回答
“我会先说明选择器和 null 策略。Java 25 的 JEP 507 仍是预览特性，不能说成稳定语法。原始类型模式让 instanceof、switch 和 record pattern 的表达更统一，但不会让缩窄自动无损。int 扩宽为 long 保留所有值，long 转 int 需要范围证明。对于包装输入，我处理 null，区分包装类型，并单独分类 NaN 与无穷大。每个 switch 都有明确的剩余分支，守卫分支不能提供完整覆盖。若生产不能固定 Java 25 和预览开关，我保留包装模式或显式检查，并在 CI 同时验证两条路径。测试包括 null、数值边界、越界值、NaN、无穷大、未知包装类型、守卫未命中和非预览编译。”
常见错误
- 把预览语法说成稳定能力 → 后续 JDK 可能改变或删除 → 固定 JDK 并保留回退。
- 认为任何数值转换都安全 → 缩窄可能丢位或拒绝值 → 说明转换方向并证明范围。
- 让
default吸收 null → null 与未知类型需要不同处理 → 加入case null或在匹配前拒绝。 - 把 double 匹配当成有限值 →
NaN与无穷大仍是该类型 → 显式测试和分类。 - 把带守卫分支当成穷尽 → 不满足守卫的值仍未匹配 → 增加无守卫剩余分支并测试覆盖。
追问及应对
long 模式可以安全绑定 int 选择器吗？
可以，因为扩宽保留 int 的全部值。反向转换一般不安全，long 可能超过 int 范围。如果业务有范围保证，就把检查写出来并测试两端边界。
为什么不把所有值都装箱？
装箱便于检查异构输入，但会引入包装语义和可能的分配，仍不能证明转换保值。选择装箱应基于 API 兼容性，而不是逃避数值推理。
如何测试预览实现？
让预览实现和稳定回退运行同一组用例：null、零、最小最大值、刚越界的值、NaN、正负无穷、未知包装类型、守卫未命中和非法输入。CI 固定精确 release 与预览开关，再运行非预览兼容任务。
Java 26 改变预览规则怎么办？
把语言级别视为产物契约。阅读新版本说明，编译候选分支，拿回退测试对照语义，只有源码和运行时矩阵通过才推广。不要在生产中静默打开新的预览开关。