内部类应仅访问外部类必要成员，优先通过参数传入数据并明确回调方式；非必要时用静态内部类避免内存泄漏；代码超150行、被外部引用或需序列化时应拆为顶层类；其合理性取决于逻辑是否专属外部类、是否误导为通用工具、是否影响外部类可维护性。
内部类确实能帮外部类把辅助逻辑“收拢”在自己内部，但用不好反而会破坏封装性——关键不在“能不能用”，而在“该不该让它知道”。
内部类该访问哪些外部成员？
优先只访问外部类的 必要字段和方法，避免直接读写外部类的私有状态。如果内部类频繁修改外部类的私有变量，说明职责边界模糊了。建议：
- 把需要共享的数据通过构造参数或方法参数传入，而非依赖隐式引用（
this） - 对外部类的回调尽量走明确的 public 或 package-private 方法，而不是让内部类直接调用 private 方法
- 若内部类仅需读取某几个字段，考虑提取为不可变对象（如 record）再传入，进一步降低耦合
用静态内部类还是非静态？
是否持有外部类实例引用，直接影响生命周期和内存安全：
- 不需要访问外部类成员 → 用 static 内部类，避免隐式强引用导致外部类无法回收
- 需要访问外部类状态 → 非静态内部类可接受，但要留意它可能延长外部类生命周期（尤其在异步、监听器等场景）
- 若只是临时组织逻辑，且不涉及状态共享，更推荐独立顶层类 + 明确依赖注入
何时该把内部类拆出去？
当内部类开始出现以下信号，就该考虑外提：
- 代码行数超过 150 行，或承担多个职责（比如既做解析又做校验还做转换）
- 被其他类（非当前外部类）间接使用，比如测试中 mock 它、或日志/监控中单独引用它
- 需要被序列化，而外部类不适合参与序列化流程（比如含线程、资源句柄等）
- 内部类本身有了子类、实现了接口、或需要被 Spring 等框架管理
封装性不是“藏起来”，而是“控制可见性”
内部类真正的价值，是把本就属于外部类语义边界的逻辑局部化；不是为了“省得建新文件”，而是为了减少不必要的公开契约。判断标准很简单：
- 这个逻辑是否只对当前外部类有意义？
- 把它暴露为 public 类，是否会让人误以为它是通用工具？
- 去掉它后，外部类是否变得难以理解或维护？
满足其中两条以上，内部类就是合理选择；否则，宁可多一个文件，也要守住接口的清晰边界。
