局部变量不能被内部类延长生命周期，而是编译器将其值或引用复制为内部类私有字段（如val$counter）；必须effectively final以保证一致性，可通过数组、AtomicInteger等包装实现状态更新，但需警惕内存泄漏。
方法局部变量本身不能被内部类“延长生命周期”，真正发生的是：编译器把变量的值或引用“搬进”内部类实例中，绑定在堆上共存亡。这不是魔法，而是明确的复制+引用绑定机制——理解这点，就绕开了绝大多数困惑。
为什么局部变量必须是 effectively final
局部变量存在栈上，方法一结束，栈帧销毁，原始变量就没了；而内部类对象可能长期存活（比如作为回调、线程任务）。若允许修改原始变量，而内部类用的是旧副本，两边就会不一致。
加 final（或保持 effectively final）是向编译器承诺：“这个值/引用初始化后不会变”。它才敢安全地把值（基本类型）或引用（对象类型）拷贝一份，存为内部类的私有字段（如 val$counter），后续所有访问都走这个字段。
如何观察“变量搬家”效果
写个小实验就能验证：
- 在方法里创建一个对象，比如 Counter c = new Counter("local")
- 定义局部类并访问 c，再把它赋给一个静态字段（模拟长生命周期持有）
- 方法执行完，手动触发 GC —— c 不会被回收
- 只有清空那个静态引用后，c 才真正释放
这说明：局部类实例持有了对 c 的强引用，变量不是“活久一点”，而是“换地方住”了。
想改状态？别动变量，动它里面的内容
final 限制的是引用或值本身不可再赋值，但不禁止修改所指向对象的内部状态。常用绕过方式：
- 用 int[] arr = {0}，然后在内部类里写 arr[0]++
- 用 AtomicInteger counter = new AtomicInteger(0)，调用 counter.incrementAndGet()
- 自定义包装类：class Box { int value; }，内部类里改 box.value = 1
这些方案都利用了“引用 final，内容可变”的特性，既满足编译要求，又保留了状态更新能力。
常见陷阱：内存泄漏风险
局部类隐式持有对外部变量的引用，如果这个内部类实例被长期持有（比如注册成全局监听器、放进静态缓存），它所捕获的对象也会一直无法回收。
尤其要注意 Activity 或 Fragment 中的局部类——若捕获了它们的引用，容易导致界面销毁后仍被持有，引发内存泄漏。必要时用弱引用或及时清理外部引用。
