成员内部类适合封装紧密依赖外部类状态且无需对外暴露的私有算法，如链表节点操作、树遍历、交易校验等；应定义为private final，不提供工厂方法或public返回类型，专注纯逻辑计算，副作用由外部类处理。
成员内部类适合封装哪些私有算法
当算法逻辑紧密依赖外部类的状态，又不需要被外界直接调用时，成员内部类是最自然的选择。它能直接读写外部类的私有字段和方法，避免参数传递冗余，也防止算法被误用或绕过校验流程。
典型场景包括：链表节点操作、树遍历策略、交易合法性校验、任务有效性判断、订单状态转换规则等。这些算法往往涉及多步条件检查、状态变更和副作用，放在内部类里既清晰又安全。
定义私有成员内部类并限制访问范围
用 private 修饰内部类，确保它只能被外部类访问。外部代码无法 new 它、继承它，也无法反射获取其实例——这是实现真正封装的第一步。
- 不要加 public 或 protected，哪怕类名看起来“通用”
- 不提供静态工厂方法暴露内部类类型
- 避免在 public 方法签名中返回内部类类型（如不写
public Validator getValidator()）
例如链表实现中，private class Node 封装了数据与指针结构，外部连 new Node() 都做不到，彻底隐藏了底层表示。
让内部类专注单一职责，通过外部类统一调度
内部类不做决策出口，只做计算与验证；真正的业务动作（如修改状态、触发回调）仍由外部类完成。这样既保持职责分离，又守住封装边界。
- 内部类里只放 isValid()、calculateScore()、buildPath() 这类纯逻辑方法
- 所有副作用操作（如更新 balance、添加到 tasks 列表、抛异常）保留在外部类方法体内
- 内部类可设为 final，防止被子类篡改行为
像 BankAccount.TransactionValidator 只回答“能不能取”，不执行扣款；TaskManager.TaskProcessor 只判断任务是否有效，不直接 add 到列表——决定权始终在外层。
注意生命周期与对象创建方式
成员内部类实例隐式持有外部类引用，创建时必须依托外部类对象。这点既是优势（可自由访问私有状态），也是潜在风险（容易引发内存泄漏或意外耦合）。
- 用
new Outer().new Inner()创建，不能脱离外部实例 - 避免在 long-lived 场景（如静态缓存、线程池任务）中长期持有内部类实例
- 若算法无需访问实例状态，优先考虑静态内部类，更轻量且无引用绑定
比如解析器类如果只处理传入参数、不读写外部字段，就该改成 public static class Parser，而不是成员内部类。
