局部内部类只能在定义它的方法内使用，编译后生成数字编号类文件（如OuterClass$1.class），无正式类名，不可被外部访问或实例化。
局部内部类只能在定义它的方法里用
Java 里定义在方法内部的类叫局部内部类，它不是成员，不归类文件直接管理，编译后生成 OuterClass$1.class 这样的匿名编号名（不是 OuterClass$LocalClassName.class），连名字都不保留——所以你根本没法在方法外 new 它，也没法被其他类引用。
常见错误现象：Cannot resolve symbol 'MyLocal' 或 class MyLocal is not public，其实不是访问权限问题，是它压根“不存在于作用域之外”。
- 只能在声明它的方法体内实例化，比如
new MyLocal().doWork() - 不能加访问修饰符（
public/private等）——语法直接报错 - 不能是
static——局部内部类天然不支持静态成员（除了静态常量static final） - 可以访问所在方法的
final或“事实上 final”的局部变量（Java 8+ 放宽了限制，但语义没变）
为什么局部内部类能访问外部方法的变量
不是靠反射或运行时偷看，而是编译器在生成字节码时，把那些被引用的局部变量“拷贝”进局部内部类的构造器，并作为私有字段存起来。所以你看到的“访问”，其实是隐式传参 + 字段持有。
使用场景：需要封装一小段逻辑，又想轻量复用方法内变量，比如事件回调、临时策略、延迟初始化中的闭包行为。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
- 如果变量在方法里被修改过，且局部内部类又用了它，编译会拒绝——除非你把它声明为
final，或确保它“事实上 final”（Java 8+） - 注意对象引用和值的区别：
String s = "hi"被捕获后，改s = "bye"不影响内部类持有的旧引用；但改list.add(1)会影响，因为引用指向的是同一个对象 - 性能上无额外开销，只是多一次字段赋值和内存持有，但生命周期绑定到内部类实例，可能延长外部变量的存活时间
局部内部类 vs 匿名内部类 vs Lambda
三者都能实现“方法内定义行为”，但意图和约束完全不同。
- 局部内部类可以有名字、可重复 new 多次、可定义多个方法、可继承类或实现多个接口——适合稍复杂的临时逻辑
- 匿名内部类没名字、只能用一次、必须基于某个类型（类/接口），写法紧凑但不可复用——适合简单回调
- Lambda 只适用于函数式接口（且仅一个抽象方法），不能访问非 final 局部变量，也不能定义字段或构造器——适合极简行为传递
- 别为了“看起来高级”硬套 Lambda：如果需要在内部类里调用两次以上、或要持有一些状态字段，老老实实写局部内部类，别拆成两个 Lambda 或塞一堆闭包变量
编译后看不到类名，调试时怎么定位
反编译 javap -c OuterClass\$1.class 会看到真实类名是数字编号，IDE 调试时栈帧里显示的也是类似 OuterClass$1。这不是 bug，是设计使然。
容易踩的坑：日志打点、序列化、框架反射扫描（比如 Spring 的 @Component 扫描）完全忽略局部内部类——它不在类路径的“可见类型”里。
- 如果需要被框架识别或跨方法传递，不要用局部内部类，改用私有成员内部类（
private class Helper） - 单元测试中无法直接 new 局部内部类，只能通过宿主方法触发其逻辑——意味着你要测的是方法行为，而不是这个类本身
- 混淆工具（如 ProGuard）默认不处理局部内部类，因为它们本就不该被外部引用；但如果你误用了反射去加载
OuterClass$1，混淆后必崩
