Java对不可达代码的判定依据来自Java语言规范第14.21节，而不是依靠编译器的数据流分析或路径敏感分析。一个典型疑问是：当if条件写成常量true时，else分支明显永远不会执行，为什么编译器不把其中的return标记为unreachable code？这背后是Java语言规范为if语句专门设计的一条可达性规则。
简单来说，if语句的then分支和else分支是否可达，只取决于整个if语句本身是否可达，而不会参考条件表达式是否被求值为常量。这个规则与while语句、for语句形成鲜明对比，理解这个差异有助于开发者写出更可靠的代码，也避免把编译器的行为误读为bug。
一、不可达代码判定：规范规则优先于直觉
很多开发者对不可达代码的理解来自直觉：某行代码永远不会执行，就应该报错。但Java编译器只对Java语言规范明确列出的不可达语句报错。例如一个方法在return语句之后的语句，规范会判定为不可达，编译直接失败。
public class UnreachableDemo {
public void demo() {
return;
// 这一行会被编译器判定为unreachable statement
System.out.println("unreachable");
}
}
但是if-else结构的情况不同。根据JLS规定，对于if-then-else语句，then分支和else分支的可达性都等同于整个if语句的可达性。也就是说，只要执行流有可能进入这条if语句，那么两个分支在规范层面都被认为是可达的。编译器不允许进一步根据条件常量推断某一分支不可达，否则会破坏Java语言关于条件编译的设计。
这种刻意弱化的可达性分析，并不是编译器实现上的疏漏。Java编译器遵循的是语言规范定义的精确边界，而不是不受约束的静态分析。理解这一点，是理解后续示例的行为基础。
二、用常量条件验证else分支的特殊性
先看一个直观的例子。尽管if的条件是常量true，else分支中的return语句仍然不会触发编译错误。
public class ConstantIfDemo {
public int constantBranch() {
if (true) {
return 1;
} else {
// 从运行路径看这个return永远不可能执行
return 2;
}
}
}
如果实际运行constantBranch方法，只会返回1。但运行路径上的不可能性，不会改变编译期的可达性判断。可达性规则规定，只要整个if语句是可达的，else分支就是可达的，因此编译器不会报告unreachable code。
与此形成对比的是while语句。Java规范对while条件为常量false的情况做了特殊处理，循环体会被判定为不可达。
public class WhileFalseDemo {
public void whileFalse() {
while (false) {
// 这个循环体会被编译器判定为不可达
System.out.println("never");
}
System.out.println("after loop");
}
}
同样是由常量条件导致的永不执行路径，if语句的else分支被保留，而while语句的循环体却会报错。这种不一致并非偶然，而是因为if常量条件需要承担条件编译职责，while(false)却没有类似需求。规范通过不同的可达性规则，平衡了语言灵活性问题和尽早暴露无意义代码的需求。
三、条件编译：设计意图与字节码层面的表现
Java没有C/C++那样的预处理宏，但开发者经常使用static final布尔常量作为特性开关，让同一份源码支持不同配置。这种场景下，if语句的两个分支都必须保持可编译状态。
public class FeatureSwitch {
public static final boolean NEW_ALGORITHM = false;
public int process(int value) {
if (NEW_ALGORITHM) {
return value * 2;
} else {
return value + 1;
}
}
}
在这个例子中，NEW_ALGORITHM被定义为false，但else分支不会被当作不可达代码。如果编译器把else分支判定为unreachable，那么所有依赖常量开关的条件编译代码都将无法通过编译，这与Java的设计目标直接冲突。因此，JLS刻意规定if语句的分支可达性不受条件常量影响。
在字节码层面，javac通常不会对if常量分支做激进的删除优化。它仍然按照两个分支的结构生成指令，真正消除死路径的工作更多留给JIT编译器在运行时完成。这样既保证了编译期可达性规则的稳定性，也让条件编译开关可以灵活调整。开发者修改布尔常量后重新编译，两个分支始终都处于可编译状态，不会因为打开或关闭某个特性而触发大面积unreachable错误。
四、不可达与死代码的区别及开发建议
需要明确区分两个概念：unreachable statement是JLS规定的编译期错误，而dead code是实际执行不到的代码，但不一定触发编译错误。else分支中的return在常量true条件下属于死代码，但它是JLS定义的可达语句。因此，编译器不报错不代表代码没有问题。恒定条件往往隐藏着业务逻辑错误、遗留调试代码或特性开关使用不当。
建议开发者不要把常量布尔判断直接散落在业务方法中。如果确实用于特性开关，应将常量集中在配置类中统一管理，并配合代码审查和静态分析工具检查恒定条件分支。像SpotBugs、SonarQube这类工具能识别部分死代码，但javac本身不会主动提示。理解编译器的可达性规则边界，可以帮助我们更准确地预期工具行为，而不是把一切逻辑问题都寄希望于编译错误。
回到标题的问题，Java编译器不将else分支中的return视为不可达代码，是因为JLS对if语句的可达性规则不评估条件常量，这是为了支持条件编译而做出的刻意设计。它与while(false)的规则不同，也不是编译器能力不足。开发中应结合静态分析工具排查真正的死代码，而不是依赖javac的unreachable检查。