局部内部类适用于方法内一次性、强耦合的临时逻辑，需同时访问外部类成员和方法局部变量且可能延迟执行；须满足effectively final约束，警惕内存泄漏，建议简洁单一、及时提取为顶层类。

局部内部类适合在方法内封装一次性、强耦合的临时逻辑，比如事件回调、状态封装或异步处理中的上下文绑定。它不是为复用设计的，而是为“此刻这个方法里需要一个带状态的小工具”而存在。

明确适用场景：什么情况下该用局部内部类

当一段逻辑只服务于当前方法，且需同时持有：
– 外部类的实例成员（如 private 字段、this 引用）
– 方法内的某些局部值（如配置参数、临时计算结果）
– 并可能被延迟执行（如传给线程、监听器、定时器）时，局部内部类比单纯传参更自然。

• 例如：启动一个后台任务，既要读取外部类的 service 对象，又要记住本次调用的 timeout 值和 callback 函数
• 再如：GUI 中为某个按钮点击定义专用处理器，需访问当前方法中生成的 dialog 实例和用户输入的 id
• 不适用的情况：逻辑要被多个方法复用、需序列化、或生命周期明显长于方法调用（如注册为全局监听器后长期存活）

正确捕获局部变量：final 和 effectively final 的实操要点

JDK 8+ 允许省略 final 关键字，但前提是变量在初始化后**不再被重新赋值**——编译器会自动将其视为 effectively final。这不是语法糖，而是语义约束。

• 基本类型（int、boolean 等）：只要不写 a = 10; 这类赋值语句即可
• 引用类型（List、String、自定义对象）：不能重新指向新对象，但可修改其内容（如 list.add("x") 合法，list = new ArrayList(); 不合法）
• 常见陷阱：在局部内部类创建前就对变量做二次赋值，哪怕只是条件分支里的赋值，也会导致编译失败

避免内存泄漏：警惕隐式持有的对象引用

局部内部类实例一旦被外部持有（如注册到线程池、事件总线、静态容器），它所捕获的每个局部变量（及其引用的对象）都会持续驻留内存，哪怕原方法早已返回。

• 尤其注意大对象：byte[]、Bitmap、大集合、完整 DTO 实体等，不要直接捕获，改用 ID、key 或轻量字段
• 推荐做法：若只需某个字段值，显式通过构造参数传入，而非依赖闭包捕获 —— 更清晰，也更容易做 null 检查和生命周期控制
• 调试提示：用 VisualVM 或 MAT 查看堆中内部类实例的引用链，确认是否意外延长了无关对象的存活时间

代码结构建议：保持简洁，不嵌套过深

局部内部类本身不支持 static、不能有访问修饰符（public/private 等），也不参与类加载。它的存在只为当前方法服务，因此应：

• 控制行数：建议不超过 30 行，职责单一（如仅实现 Runnable 或 ActionListener）
• 命名清晰：用有意义的类名（如 TimeoutHandler、RetryPolicy），而非 Inner 或 Worker
• 避免在局部内部类里再定义内部类：Java 允许，但可读性和维护性急剧下降
• 如果逻辑开始膨胀，说明它已超出“临时行为”范畴，应提取为独立顶层类或静态内部类