Java要求局部变量为effectively final，是因为匿名内部类对象生命周期可能长于方法栈帧，需通过值拷贝确保内外一致性；编译器静态检查变量是否未被重新赋值，以保证语义安全。
因为局部变量存在栈上，方法执行完就销毁；而匿名内部类对象在堆上，可能长期存活。两者生命周期不匹配，Java 通过编译期“值拷贝”来桥接——把变量值复制一份作为内部类的隐式字段（如 val$xxx），这就要求原始变量不能被修改，否则副本和原始值会不一致。
栈和堆的生命周期根本错位
方法内的局部变量随栈帧一起入栈、出栈，方法结束即不可访问；但匿名内部类实例是普通对象，分配在堆中，可能被线程持有、注册为回调、放进集合里长期引用。比如动画结束回调、网络响应处理、Swing 事件监听——这些执行时间远晚于原方法返回。若允许直接引用栈上变量，运行时大概率访问已销毁内存，引发不可预测行为。
编译器用“快照拷贝”代替实时引用
Java 不支持堆对象动态追踪栈变量，所以编译器主动规避风险：
- 检测到某个局部变量被匿名内部类引用，就把它当前的值（基本类型是数值本身，引用类型是对象地址）拷贝一份；
- 在生成的内部类字节码中，新增一个隐式的 final 字段（反编译可见 val$xxx）存储该拷贝；
- 内部类所有对该变量的读取，实际都转为读这个隐式字段。
这个机制叫“值捕获（value capture）”，本质是静态快照，不是共享引用。
立即学习“Java免费学习笔记（深入）”；
final 是保障语义一致性的必要约束
如果允许变量后续被修改，就会出现两种矛盾：
- 外部改了，内部类还在用旧快照 → 数据不同步；
- 内部类也想改（虽然语法禁止），但改的只是副本，对外部无影响 → 逻辑混乱。
声明为 final（或 Java 8 起的“事实上 final”）从源头杜绝赋值，让“原始变量”和“内部类副本”在语义上始终等价——它们本就是同一个不可变的值。
为什么成员变量不需要 final
外部类的成员变量（实例字段）天然存于堆中，生命周期与外部类实例一致。内部类持有对外部类实例的隐式引用（Outer.this），访问成员变量本质是通过该引用来读取堆上的数据，不存在栈/堆生命周期冲突，因此无需 final 保护。
