成员内部类是封装强耦合逻辑的天然选择，它能直接访问外部类私有成员，编译器自动生成桥接方法；适合仅服务于本类的状态相关逻辑，但需避免内存泄漏与设计滥用。

内部类是封装强耦合逻辑的天然选择，关键不在“能不能写进去”，而在于“为什么必须这么写”。它让本该只属于一个类的协作行为真正归属其中，不暴露、不污染、不越界。

成员内部类直接访问外部类私有成员的原理与写法

成员内部类能读写外部类的 private int count、调用 private void update()，不是编译器“开后门”，而是 Java 规范明确允许的行为。编译后，javac 会为被访问的私有成员自动生成 package-private 桥接方法（如 access$100(Outer)），供内部类安全调用。

• 无需 getter/setter：外部类字段可直接使用，比如 value++ 或 history.add(value)
• 同名变量要区分：若内部类也有 int value，用 OuterClass.this.value 明确指向外部字段
• 静态成员照常访问：外部类的 static final String TAG 可直接引用，不需加前缀
• 不能访问外部类的局部变量：方法内定义的变量必须是 final 或 effectively final，否则编译报错

用成员内部类封装“仅服务于本类”的业务逻辑

当一段逻辑高度依赖外部类实例状态，又不该被其他类调用时，成员内部类是最贴切的容器。它比私有方法更独立（可持状态、可多实例），比独立类更安全（完全对外不可见）。

• 适合场景：交易处理器、撤销管理器、状态校验器、事件响应器
• 典型结构：外部类提供 public Inner getHelper() 方法返回实例，不暴露内部类类型
• 避免 public 内部类：除非真要开放给外部使用，否则一律用 private class Helper
• 不要在内部类里写 static 方法：非静态内部类本身不允许定义静态成员（常量除外）

访问外部变量时的常见陷阱与解法

访问出错往往不是语法问题，而是生命周期或作用域理解偏差。重点盯住两点：是不是实例成员？是不是方法里的局部变量？

• 静态内部类无法访问非静态字段：写 static class Parser 却去读 private String data → 编译失败
• 匿名/局部内部类访问局部变量：变量中途被重新赋值 → 编译报错 “variable is accessed from within inner class”
• 正确做法：把变化值包装进 AtomicInteger 或 int[]，或改用外部类字段
• Android / Swing 中慎用：非静态内部类作为监听器或异步任务，容易导致 Activity 或窗体无法回收

什么时候该换别的方案？

内部类不是银弹。如果发现内部类开始“向外伸手”，就该反思设计是否合理。

• 需要跨多个外部类复用 → 提取为独立工具类，别硬塞进某个内部类
• 逻辑只是简单判断或计算 → 用 private 方法更清晰，不必升格为类
• 内部类频繁修改同一组字段，且字段本身已很复杂 → 考虑提取为 Value Object，由外部类传入传出
• Lambda 可替代匿名内部类时（如单方法接口），优先用 Lambda：更轻、无隐式引用、语义更聚焦