匿名内部类访问局部变量必须加final，是因为局部变量存于栈中、方法结束即销毁，而内部类对象在堆中可能长期存在；Java通过编译时复制值/引用并存为内部类私有字段来解决生命周期不一致问题，final确保副本与原始值始终一致。
为什么匿名内部类访问局部变量必须加 final？
根本不是语法“规定”，而是 JVM 对生命周期和数据一致性做出的硬性保障。局部变量存在栈上，方法一结束就销毁；而匿名内部类对象在堆上，可能活很久（比如作为回调、线程任务、监听器）。如果允许它直接读写一个早已“消失”的局部变量，程序早崩了。
Java 的解法是：编译时把那个局部变量的值（或引用）悄悄复制一份，塞进匿名内部类的构造方法里，变成它自己的私有字段。但这就引出新问题——如果外部还能改原变量，内部类里的副本就跟它对不上了。
-
final不是为了“禁止修改”，而是让编译器能确信：这个值/引用从初始化起就不会变 → 副本和原始值天然一致 - 对基本类型，保证值不变；对引用类型，保证引用不指向别处（对象内部状态仍可变）
- 没加
final却没报错？那是 Java 8+ 的“有效 final”（effectively final）在兜底——只要没被重新赋值，编译器就自动当它是final
哪些变量必须加 final？哪些不用？
只有一种情况强制要求：方法内定义的局部变量或形参，且被该方法内的匿名内部类（或局部内部类）直接访问。其他所有场景都不需要。
- ✅ 必须加（或保持 effectively final）：
int count = 5;、String msg = "done";、View v = findViewById(R.id.btn); - ❌ 不用加：
this.name（外部类成员变量）、static int FLAG（类变量）、Runnable r = () -> {}（Lambda 表达式本身不要求显式final，但捕获的局部变量仍需 effectively final） - ⚠️ 注意：匿名内部类里能访问
final局部变量，但不能访问非final的同名局部变量，哪怕没冲突也会编译失败
不加 final 会遇到什么错误？
编译直接报错，不是运行时异常，IDE 通常高亮提示：Variable used in lambda expression should be final or effectively final 或类似表述（JDK 版本不同措辞略有差异）。
常见诱因：
- 声明后又重新赋值：
int retry = 0; retry++; // ❌ 破坏 effectively final - 在 if/for 里多次赋值：
String status; if (ok) status = "success"; else status = "fail"; // ❌ 编译不过 - 试图在匿名内部类里修改它：
new Thread(() -> { counter++; }).start(); // ❌ counter 必须 final，不能++
修复方式很简单：提取为不可变表达式，或改用包装类/数组（不推荐，只为说明原理）：
final int[] counter = {0}; // ✅ 数组引用不变，内容可改（但语义已混乱，慎用）
Java 8 以后可以不写 final 关键字，那还要不要写？
技术上可以省略，编译器认得出；但工程实践中，建议保留显式的 final。
- 明确传达意图：这个变量就是设计为“只读传递”，不是遗漏或疏忽
- 避免重构风险：别人后续加一行
count = 100;就会让整个匿名内部类失效，加final是第一道防线 - 增强可读性：看到
final View view就知道它不会被重赋值，也不用担心内部类拿到的是旧引用
真正容易被忽略的点是：这个限制只针对“方法内定义的局部变量”。一旦你把它提到成员变量级别，哪怕非 final，也能被匿名内部类自由读写——因为此时访问走的是 OuterClass.this.xxx，生命周期完全由外部类实例控制。
