final局部变量成为编译期常量需同时满足：声明即初始化、类型为基本类型或String、右侧为编译期可确定的常量表达式；否则仅为普通final变量，不可用于switch case或注解值。
要真正理解 final 局部变量何时能成为编译期常量，关键不是背规则，而是动手写几组对比代码，观察编译器反应和字节码行为。下面用最贴近开发场景的方式拆解核心约束。
声明即初始化：一步到位才被认可
编译器只认“声明语句中带等号”的写法。哪怕逻辑上只赋一次值，拆成两行就失效：
-
✅ 合法（编译期常量）：
final int port = 8080;、final String env = "prod" + "_stage"; -
❌ 非法（不是编译期常量）：
final int port;然后下一行port = 8080;—— 编译报错 “variable port might not have been initialized” -
⚠️ 注意：即使加了 if-else 保证必走一条分支，如
final String s; if (true) s = "ok"; else s = "no";，s 仍是普通 final 局部变量，不是编译期常量，不能用于 switch case 或注解值
类型与表达式：只有基本类型和 String + 常量表达式才够格
不是所有 final 变量都能被内联。必须同时满足：类型是基本类型或 String，且右边是编译器能静态算出结果的表达式：
-
✅ 合法：
final int a = 10 * 2 + 5;、final String s = "hello" + "world";、final char c = 'A' + 1; -
❌ 非法：
final Integer x = 100;（包装类是引用类型）、final String t = new String("abc");（new 表达式不可编译期求值）、final long now = System.currentTimeMillis();（运行时方法调用） -
? 小技巧：把
final String s = "a"; final String t = s + "b";放在一起写，t 也能成为编译期常量——因为 s 是前面已声明的、确定的 final 局部变量
实战验证：看字节码或用 switch / 注解反推
光看编译是否通过还不够，得验证它是否真被当作编译期常量处理：
-
用 switch 测试：写
switch (value) { case port: ... }，如果 port 不满足三条件，编译直接失败：“case expression must be constant expression” -
用注解测试：写
@RequestMapping(path = env)，若 env 不是编译期常量，IDE 和编译器都会标红报错 -
查字节码（进阶）：用
javap -c查看 class 文件，如果某处直接出现iconst_8080而不是getstatic或局部变量读取，说明已被内联
别混淆：final 局部变量 ≠ 编译期常量
很多开发者误以为只要加了 final 就是“常量”，其实只是“不可再赋值”。二者区别直接影响功能可用性：
- final 局部变量：保证变量绑定不改变，适合防止误修改，lambda 捕获也依赖此约束
- 编译期常量：额外要求类型+初始化方式，目标是让编译器做优化（内联、校验、生成常量池条目）
-
典型后果：一个
final int code = getErrorCode();在 try-catch 中初始化，它是合法的 final 变量，但无法用在注解里，也不能作为 switch 的 case 值
