内部类应仅访问外部类必要成员，优先通过参数传入数据并明确回调方式；非必要时用静态内部类避免内存泄漏；代码超150行、被外部引用或需序列化时应拆为顶层类；其合理性取决于逻辑是否专属外部类、是否误导为通用工具、是否影响外部类可维护性。

内部类确实能帮外部类把辅助逻辑“收拢”在自己内部，但用不好反而会破坏封装性——关键不在“能不能用”，而在“该不该让它知道”。

内部类该访问哪些外部成员？

优先只访问外部类的 必要字段和方法，避免直接读写外部类的私有状态。如果内部类频繁修改外部类的私有变量，说明职责边界模糊了。建议：

• 把需要共享的数据通过构造参数或方法参数传入，而非依赖隐式引用（this）
• 对外部类的回调尽量走明确的 public 或 package-private 方法，而不是让内部类直接调用 private 方法
• 若内部类仅需读取某几个字段，考虑提取为不可变对象（如 record）再传入，进一步降低耦合

用静态内部类还是非静态？

是否持有外部类实例引用，直接影响生命周期和内存安全：

• 不需要访问外部类成员 → 用 static 内部类，避免隐式强引用导致外部类无法回收
• 需要访问外部类状态 → 非静态内部类可接受，但要留意它可能延长外部类生命周期（尤其在异步、监听器等场景）
• 若只是临时组织逻辑，且不涉及状态共享，更推荐独立顶层类 + 明确依赖注入

何时该把内部类拆出去？

当内部类开始出现以下信号，就该考虑外提：

• 代码行数超过 150 行，或承担多个职责（比如既做解析又做校验还做转换）
• 被其他类（非当前外部类）间接使用，比如测试中 mock 它、或日志/监控中单独引用它
• 需要被序列化，而外部类不适合参与序列化流程（比如含线程、资源句柄等）
• 内部类本身有了子类、实现了接口、或需要被 Spring 等框架管理

封装性不是“藏起来”，而是“控制可见性”

内部类真正的价值，是把本就属于外部类语义边界的逻辑局部化；不是为了“省得建新文件”，而是为了减少不必要的公开契约。判断标准很简单：

• 这个逻辑是否只对当前外部类有意义？
• 把它暴露为 public 类，是否会让人误以为它是通用工具？
• 去掉它后，外部类是否变得难以理解或维护？

满足其中两条以上，内部类就是合理选择；否则，宁可多一个文件，也要守住接口的清晰边界。