因为 jvm 的 tableswitch 和 lookupswitch 指令要求跳转目标在类加载时确定，故 case 必须是编译期常量；否则编译报错“constant expression required”，不退化为 if-else。
为什么 switch 的 case 只能用编译期常量
因为 JVM 的 tableswitch 和 lookupswitch 字节码指令，要求跳转目标必须在类加载时就确定。如果允许运行时变量（比如 new String("a") 或方法调用结果），JVM 就没法生成这些静态跳转表，也就没法做 O(1) 查找优化。
Java 编译器会把符合条件的 switch 编译成高效字节码；一旦 case 值不满足「编译期常量」条件，就会直接报错 constant expression required，而不是退化成 if-else。
-
final int x = 5;✅ 是常量（x被赋值为字面量且不可变） -
final int y = someMethod();❌ 不是常量（方法调用在运行时才执行） -
String s = "hello"; case s:❌ 即使字符串字面量是常量，变量s本身不是编译期常量 -
case "hello":✅ Java 7+ 支持字符串字面量（编译器会转成hashCode()+equals()双重校验）
哪些值算「编译期常量」：看 final + 字面量 + 无运行时依赖
判断标准很实在：这个值能不能在 .class 文件里被写死？能不能被 javac 在编译阶段完全算出来？
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 基本类型字面量：
case 42:、case 'a':、case true: - 被
final修饰的静态/非静态字段，且初始化是字面量或常量表达式：static final int MAX = 100 + 1; - 字符串字面量：
case "done":（注意：不是 new 出来的，也不是拼接的"a" + getSuffix()） - 枚举常量：
case Color.RED:（本质是编译期确定的唯一实例引用） - 但
case Integer.valueOf(42):❌ 不行，这是运行时对象构造
想绕过限制？别硬刚编译器，换思路
如果你发现 case 值必须动态计算，说明 switch 本来就不该用在这里——它不是万能分支工具，而是针对「有限、确定、静态」选项的性能优化语法糖。
- 用
if-else显式判断：清晰、可控、无限制，适合逻辑复杂或条件带副作用的场景 - 用 Map 预热映射：
Map<string runnable> handlers = Map.of("save", this::doSave, "load", this::doLoad);</string>，适合配置驱动或策略较多的情况 - 用枚举 + 抽象方法：把行为绑定到枚举实例上，比一堆 case 更易维护（前提是枚举值本身可静态定义）
- 避免用反射或动态代理强行“模拟 switch”——性能差、调试难、容易出
NoSuchFieldException
Java 14+ switch 表达式带来的新坑
虽然 switch 表达式支持 -> 语法和返回值，但 case 值的常量约束一点没放松。反而因为更紧凑的写法，容易忽略隐含限制。
-
case x -> ...中的x还是得是常量，不能是局部变量名 -
case 1, 2, 3 ->多值匹配没问题，但所有值仍需各自满足常量要求 - 忘记加
break不再导致 fall-through？没错，但编译错误不会因此变少——case null:在非String或非枚举 switch 中仍是非法的 - IDE 可能提示「can be switched to switch expression」，但别盲目重构：先确认所有 case 值真能静态确定
最常被忽略的一点：常量性检查发生在编译期，而某些看似固定的值（比如通过 Class.forName() 加载的类名、从配置文件读的字符串）哪怕每次运行都一样，也不算编译期常量——它们根本进不了 class 文件的常量池。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
