为何Java中if条件内的instanceof变量可在外部访问？

核心原因：编译器的可达性分析与明确初始化规则 #

在Java 16及以上引入的instanceof模式匹配中，变量的可见性并非仅由代码块范围决定，编译器会通过可达性分析判断变量是否在某个代码点被明确初始化：

你的代码中，if条件是取反后的逻辑：

if (!(datos.get("tipo") instanceof String tipo && tipo.equals("A"))) {
    throw new RuntimeException("Error");
}
System.out.println(tipo);

当程序能执行到System.out.println(tipo)这一行时，说明前面的if条件必然为false——因为如果条件为true，代码会执行throw语句直接终止方法，根本到不了后续代码。

而if条件为false等价于datos.get("tipo") instanceof String tipo && tipo.equals("A")为true，这意味着：

1. datos.get("tipo")确实是String类型，tipo变量已经被成功赋值
2. tipo.equals("A")也成立

编译器能明确推断出，到达System.out.println(tipo)时，tipo一定是已初始化且有效的，因此允许在if块外部访问这个变量。

对比其他情况的差异 #

• 去掉取反：如果条件改为if (datos.get("tipo") instanceof String tipo && tipo.equals("A"))，此时if块内部可以访问tipo，但外部不行。因为当条件为false时，程序会走到外部代码，而此时tipo并未被初始化，编译器无法保证变量的有效性，因此禁止访问。
• 去掉异常抛出：如果if块内不执行throw，那么即使条件为true，程序执行完if块后仍会走到外部代码。但编译器无法确保所有路径下tipo都被初始化（比如条件为false时tipo未赋值），因此会报错提示变量未初始化。

总结 #

这种特殊的可见性是Java编译器基于控制流分析实现的：当编译器能确定某个代码点的所有可达路径中，模式匹配变量都已被成功初始化，就会允许在该点访问变量，而不受代码块范围的限制。

内容的提问来源于stack exchange，提问作者David Salas