匿名内部类访问局部变量必须为final或effectively final，根本原因是栈帧销毁后局部变量不复存在，而内部类对象仍存活；编译器将其值快照为隐式字段存入堆中，故需确保值不变。
匿名内部类访问局部变量为何报错“Variable is accessed from within inner class”
Java 编译器强制要求匿名内部类访问的局部变量必须是 final（或“effectively final”），根本原因不是语法糖或设计偏好，而是栈帧生命周期不匹配——方法执行完，局部变量所在的栈帧就销毁了，但匿名内部类对象可能还活着。
编译器实际做的，是把那个局部变量的值在编译期“快照”一份，作为匿名内部类实例的隐式字段存进堆里。所以它必须确定这个值不会变，否则堆里的副本和原栈上“本该有的新值”就对不上了。
- Java 8+ 放宽为“effectively final”：只要没被重新赋值，即使没写
final关键字也合法 - 一旦你在方法里给变量二次赋值（哪怕只有一处），哪怕没传给内部类，整个方法里所有匿名内部类都会报错
- 成员变量、静态变量不受此限——它们生命周期在堆上，跟内部类一致
为什么String、Integer等不可变类型常被误认为“可以改”，其实只是换了引用
很多人试过这样写，发现不报错：
String s = "a"; new Thread(() -> System.out.println(s)).start(); s = "b"; // ✅ 不报错
但这不是“改了 s”，而是让局部变量 s 指向了新字符串对象；匿名内部类捕获的是旧的 "a" 的引用（或值，对基本类型而言）。真正危险的是可变对象：
立即学习“Java免费学习笔记（深入）”；
-
StringBuilder sb = new StringBuilder("hello");→ 匿名类拿到的是sb的引用，之后调用sb.append(" world")，内部类看到的就是修改后的状态 - 这不是编译器能拦住的，属于逻辑错误，容易引发竞态或脏读
- 若真需要共享可变状态，应显式使用线程安全容器（如
AtomicReference）或加锁，而不是依赖“final 引用”来掩盖问题
Java 8 以后“effectively final”的真实边界在哪
所谓“effectively final”，是指变量从声明到所在作用域结束，**一次也没被重新赋值过**。编译器检查的是赋值动作，不是类型或语义。
- 以下写法会破坏 effectively final：
int x = 1; if (cond) x = 2;→ 即使cond永远为 false，也报错 - 循环变量不能用于匿名内部类：
for (int i = 0; i → <code>i在每次迭代都被重赋值，不满足 effectively final - 想在循环中捕获索引？得手动创建一个中间变量：
final int idx = i;，再在内部类里用idx
lambda 表达式是否也受 same rule
是的，而且规则完全一致——lambda 本质就是函数式接口的匿名内部类语法糖。JVM 层面，lambda 可能被编译为 invokedynamic 调用点，但**对局部变量的访问约束没变**。
-
int x = 5; Runnable r = () -> System.out.println(x); x = 6;→ 编译失败 - lambda 捕获的也是值（基本类型）或引用（对象），不是变量本身
- 唯一区别是 lambda 更轻量，没有
this引用歧义，但生命周期一致性这个底层约束一点没放松
最容易被忽略的，是“作用域嵌套时 final 的粒度”：外层方法的局部变量 final，不代表内层 for 或 if 块里声明的变量自动 final；每个作用域单独判断。一不留神，就在嵌套块里踩了重新赋值的坑。
