instanceof 模式：判断与绑定合并

判断成功即绑定01

o instanceof String s 在判断类型的同时声明并绑定 s，匹配成功后 s 就是 String，不需要再强转。匹配失败时 s 不会被赋值。

static String normalize(Object o) {
    if (o instanceof String s && !s.isBlank()) {
        return s.strip().toLowerCase();
    }
    return "";
}

System.out.println("[" + normalize("  Hello  ") + "]");
System.out.println(normalize("   ").isEmpty());

[hello]
true

旧写法需要三步：instanceof 判断、强制转换、再访问。模式把三步压成一条声明，也消除了「判断错类型后强转」的机会。

流作用域：由控制流决定可见性02

模式变量的作用域由流分析决定，而不是声明位置所在的块。编译器只允许在「确定匹配成功」的路径上访问它。

static String upper(Object o) {
    if (!(o instanceof String s)) {
        return "not a string";
    }
    return s.toUpperCase();
}

System.out.println(upper("ok"));
System.out.println(upper(42));

OK
not a string

同理，throw、break、continue 让后续路径不可达时，编译器也会承认模式变量已绑定。这不是简单的「if 块内可见」，而是对布尔短路和控制流的完整分析。

限制与边界03

• 不能对泛型参数做具体类型判断：o instanceof List<String> l 非法，只能写 List<?> l。
• null instanceof 任何类型 都是 false，模式变量不会绑定。
• 17 只支持类型模式，不支持 record 解构；o instanceof Point(int x, int y) 要等到 21。
• switch 里的类型模式在 17 是预览，instanceof 模式本身是正式能力，两者不要混为一谈。
• 模式变量可以与已有变量同名吗？不可以，同一作用域内重复声明会编译失败。

// 合法：泛型用通配符
if (o instanceof List<?> list && !list.isEmpty()) {
    System.out.println(list.get(0));
}

// 非法：泛型参数不可具体化
// if (o instanceof List<String> list) { ... }

类型擦除决定了运行时没有 List<String> 的信息，编译器无法验证元素类型，因此禁止这种写法。需要元素类型时，只能绑定 List<?> 后逐个判断。

什么时候用、什么时候不用04

instanceof 模式最适合「一个方法里处理一两种已知类型」的场景。分支超过三四种，且类型集合封闭时，才考虑 sealed + 模式 switch；否则 if 链更易读。

版本边界BOUNDARY

这张表比 API 本身更值得记。写代码时先确认你的运行时版本。

费曼自检SELF CHECK

先合上页面，用自己的话回答，再展开对照。能讲出因果和反例，才算真正掌握。