Java编译器强制局部变量为final或effectively final，是因为内部类需复制该变量值作为隐式字段，避免栈帧销毁后访问失效及内外值不一致；成员变量则通过Outer.this引用直接访问，无需final。
Local 内部类访问局部变量时为何编译器强制 final（或 effectively final）
Java 编译器要求 Local 内部类（含匿名内部类）访问的外部局部变量必须是 final 或“事实不可变”（effectively final），根本原因不是语法偏好，而是字节码层面的实现机制决定的：局部变量在方法栈帧中存在，而内部类对象在堆中存活，二者生命周期天然不一致。编译器为解决这个矛盾，选择在生成内部类字节码时，把被引用的局部变量值“复制一份”作为内部类的隐式成员字段，并通过构造器传入。若允许修改原变量，就会出现外部改了、内部还用旧值的不一致问题。
Java 8 之后为什么可以不写 explicit final 却仍报错“needs to be final or effectively final”
Java 8 引入了 effectively final 语义，放宽了语法限制，但底层机制没变——仍是复制值、仍是禁止修改。只要你在局部变量被内部类引用后又赋新值，编译器立刻报错：Variable 'x' is accessed from within inner class, needs to be final or effectively final。这不是兼容性让步，而是编译器自动推断“你没改它”，就当它是 final；一旦有修改动作（哪怕只有一行 x = 42;），推断失败，约束立即生效。
- effectively final 是编译期静态检查，运行时无任何额外开销
- 基本类型复制值，引用类型复制引用（不是深拷贝），所以内部类看到的是同一个对象实例
- 即使你用
final Integer i = 100;，后续不能改i，但能调用i.intValue()——因为改的是对象状态，不是引用本身
反编译看真相：内部类字节码里藏着哪些隐藏字段和构造参数
写一个带局部变量引用的匿名内部类，编译后用 javap -c 反编译，会发现：内部类的构造器多了一个参数，且类里多了一个私有字段，名字通常是 val$xxx。例如：
void method() {
final String s = "ok";
Runnable r = new Runnable() {
public void run() { System.out.println(s); }
};
}
反编译出的内部类类似：
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
立即学习“Java免费学习笔记（深入）”；
class Outer$1 implements Runnable {
private final String val$s; // ← 隐藏字段
Outer$1(String s) { this.val$s = s; } // ← 隐藏构造参数
public void run() { System.out.println(this.val$s); }
}
这说明：所谓“访问外部变量”，实际是访问自己字段 val$s；所谓“final 约束”，本质是防止你在外部改了 s，却没同步到 val$s，造成逻辑割裂。
容易忽略的关键点：成员变量 vs 局部变量，待遇完全不同
外部类的成员变量（this.field）不需要 final，因为内部类持有对外部类实例的隐式引用（Outer.this），访问的是堆中同一对象的字段，生命周期由 GC 控制，不存在栈帧销毁后失效的问题。而局部变量没有这种“绑定通道”，只能靠复制+冻结来保一致性。
真正容易踩坑的地方在于：你以为改了局部变量会影响内部类，其实不会；你以为内部类改了某对象状态，外部也能看到——那得看改的是不是同一个对象。别混淆“引用不可变”和“对象不可变”。
