instanceof 判断失败的首要原因是左操作数为 null，此时恒返回 false；正确做法是先判空再 instanceof，且模式匹配需 JDK 16+（21+ 无需预览），绑定变量作用域仅限当前块。
instanceof 判断失败但对象明明是那个类型？
常见现象是 obj instanceof List 返回 false，可 obj.getClass().getName() 明明打印出 java.util.ArrayList。根本原因：左边操作数为 null —— instanceof 对 null 永远返回 false，且不抛异常。
实操建议：
- 判空必须前置：
if (obj != null && obj instanceof List) - 不要依赖
instanceof做非空断言，它不改变变量的可空性状态 - 在泛型擦除后仍能工作的场景（如反射、序列化框架），
instanceof是安全的运行时类型检查手段
Java 16+ 的模式匹配 instanceof 怎么写才不报错？
模式匹配要求 JDK ≥ 16，且需开启预览特性（编译和运行都要加 --enable-preview）；JDK 21 起转正，无需预览开关。但它只支持“局部变量声明式绑定”，不能用于字段或方法参数。
实操建议：
- 正确写法：
if (obj instanceof String s) { System.out.println(s.length()); }—— 绑定变量s作用域仅限该if块内 - 错误写法：
if (obj instanceof String s) {...} s.toString();—— 编译报错，s在块外不可见 - 不能嵌套绑定：
if (obj instanceof List合法，但list) List中的泛型信息在运行时已擦除，list类型仍是List，不是List
用 getClass() == vs instanceof，哪个更准？
getClass() == SomeClass.class 判断的是“是否为该类的**精确实例**”，不接受子类；而 instanceof 是“是否为该类或其任意子类的实例”。两者语义不同，选哪个取决于需求。
实操建议：
- 需要严格区分父类与子类时（如自定义 equals 实现），用
getClass() ==；例如ArrayList和LinkedList都是List，但你只想处理ArrayList实例 - 多数业务逻辑（如类型分发、策略选择）应优先用
instanceof，它更符合面向对象的多态直觉 -
getClass() ==在涉及代理类（如 Spring AOP 生成的 CGLIB 代理）时容易误判，因为代理对象的getClass()是动态生成的子类，不是原始类
模式匹配后强制转型还安全吗？
不安全 —— 模式匹配本身已做了类型校验，后续再显式强转（如 (String) obj）不仅冗余，还会掩盖潜在问题。尤其当变量被中途重新赋值时，IDE 或编译器无法保证后续强转仍成立。
实操建议：
- 匹配成功后直接使用绑定变量：
if (obj instanceof String s) { use(s); }，不要写成if (obj instanceof String) { String s = (String) obj; } - 绑定变量是 final 的（隐式），避免意外修改导致类型不一致
- 如果需在多个分支复用，提取为方法参数，而不是在外部强转后传入
最容易被忽略的一点：模式匹配的绑定变量名不能和已有变量重名，否则编译失败；而且一旦用了模式匹配，就别回头混用传统 instanceof + (Type) cast，两种风格混在一起会让类型流变得难以追踪。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
