java 14+ 的 instanceof 模式匹配允许在类型检查时直接绑定变量，如 if (obj instanceof string s) { ... }，变量 s 仅在该 if 块内有效，不支持 null 匹配，不突破泛型擦除限制，且需注意作用域与兼容性要求。
instanceof 后直接声明变量：Java 14+ 的新写法到底怎么写
Java 14 引入的 instanceof 模式匹配，允许你在做类型判断的同时直接绑定变量，省掉显式强转。不是语法糖，是编译器级支持，但必须满足「判定后立即使用」这个关键约束。
常见错误现象：IllegalStateException 不会报，但编译直接失败——比如把匹配后的变量用在 if 块外、或中间插了别的语句。
- 正确写法：
if (obj instanceof String s) { System.out.println(s.length()); }——s只在该if块内有效 - 错误写法：
if (obj instanceof String s) { ... }; System.out.println(s);—— 编译报错：s cannot be resolved - 也不行：
if (obj instanceof String s) { doSomething(); String t = s; }—— 中间调用方法不算“立即使用”，s作用域仍只限于条件体内部
为什么不能用于 null？null 不匹配任何引用类型模式
instanceof 模式匹配对 null 的处理和传统 instanceof 一致：一律返回 false，且不会触发变量绑定。这点容易被忽略，尤其在工具类或泛型边界判断里。
使用场景：你写了一个通用的 parseIfString 方法，传入 null 时希望跳过处理，而不是抛 NullPointerException。
立即学习“Java免费学习笔记（深入）”；
- 安全写法：
if (obj != null && obj instanceof String s) { ... } - 别指望
obj instanceof String s自动过滤null—— 它根本不会进入分支，s也不会被声明 - 对比传统写法：
if (obj instanceof String) { String s = (String) obj; ... }，两者在null行为上完全等价，只是后者多一步强转
和 switch + pattern matching（Java 17+）混用时的坑
Java 17 支持 switch 中的类型模式，但和 instanceof 模式匹配不是一回事：前者是独立语法扩展，后者仅适用于 if 条件。强行混用会编译失败。
性能影响几乎为零——两者都由 javac 在编译期展开为传统字节码，运行时无额外开销；但可读性和维护性提升明显。
- 合法：
switch (obj) { case String s -> System.out.println(s); case Integer i -> ... } - 非法：
if (obj instanceof String s) { ... } else if (obj instanceof Integer i) { ... }写成链式没问题，但别试图在switch中嵌套instanceof表达式 - 兼容性注意：Java 14–16 需开启预览特性（
--enable-preview），Java 17+ 才是正式特性
泛型擦除下，instanceof 模式匹配能匹配到泛型实际类型吗？
不能。和传统 instanceof 一样，受类型擦除限制，运行时无法获取泛型参数信息。所谓「匹配 List<string></string>」是编译器骗你的，实际只认 List。
容易踩的坑：有人以为 obj instanceof List<string> list</string> 能确保 list 里全是 String，其实它连 List<integer></integer> 都不会拦住。
- 真实行为：
obj instanceof List<string> list</string>等价于obj instanceof List list，尖括号内容被编译器静默丢弃 - 验证方式：写个
new ArrayList<integer>()</integer>传进去，它照样进分支 - 替代方案：如需运行时校验元素类型，得靠
list.stream().allMatch(...)或自定义检查逻辑
最常被忽略的一点：模式变量的作用域是词法作用域，不是控制流作用域。哪怕你用 return 提前退出、或加了 else if，只要没在同一个 if 块里声明，变量就不可见。这不是 bug，是设计使然。
