Java通过内部类模拟多重继承，解决行为组合混乱等问题：成员内部类复用父类实现，匿名内部类适配临时逻辑，静态内部类规避引用风险，结合default方法与内部类委托实现有状态复用。
Java 本身禁止类的多重继承，但内部类能以轻量、可控的方式模拟其关键特性——不是为了“绕过限制”，而是为了解决真实架构痛点：行为组合混乱、职责边界模糊、复用粒度粗、接口实现被迫耦合。核心不在“继承几个类”，而在让一个业务主体（外部类）自然承载多套独立、可插拔、有状态的行为逻辑。
用成员内部类分别继承不同父类，解耦行为与主干逻辑
当外部类已承担核心领域职责（比如 OrderService），又需要复用 PaymentProcessor 和 NotificationSender 的完整实现（含私有字段、构造逻辑、模板方法），直接让 OrderService 去继承二者不可能。此时可定义两个成员内部类：
- PaymentHelper extends PaymentProcessor：封装支付流程细节，可访问 OrderService 的订单数据（如 order.getAmount()）
- NotifyHelper extends NotificationSender：封装通知渠道选择、重试策略，直接读写 OrderService 的 status 字段
外部类通过 paymentHelper.process() 或 notifyHelper.sendSuccess() 调用，行为归属清晰，不污染主类签名，也不要求 PaymentProcessor/NotificationSender 提供无参构造或暴露敏感字段。
用匿名内部类快速适配临时行为，避免过度设计
在策略切换、事件回调、测试桩等场景，不需要长期持有某套逻辑。例如发起异步任务时需临时定制超时处理：
立即学习“Java免费学习笔记（深入）”；
- 直接 new Thread(new Runnable() { ... }) —— 过重，且 Runnable 无法携带状态
- 改用匿名内部类继承 TimeoutTask（抽象类，含 protected retryCount、onTimeout() 抽象方法）
- 只重写 onTimeout()，复用父类的计时器、日志模板、上下文绑定能力
代码紧凑、意图明确，且生命周期与当前调用栈一致，无需管理类名或包路径。若后续该逻辑被多处复用，再提取为命名内部类即可。
用静态内部类 + 接口委托，规避方法名冲突与隐式引用风险
当外部类已实现 Runnable，又需提供 Comparable 的排序逻辑，而两者都有 compareTo() 或 run() 同名方法时，直接在外部类里实现会导致语义混淆。正确做法是：
- 声明 static class Sorter implements Comparable<Order>：静态内部类不持外部类引用，无内存泄漏风险
- Sorter 构造时显式接收必要参数（如 Comparator<String> fieldComparator）
- 外部类提供
getSorter()方法返回新 Sorter 实例，调用方按需使用sorter.compare(a, b)
这样既分离了“执行”和“比较”两套契约，又避免非静态内部类因被监听器、线程长期持有而导致 OrderService 实例无法回收。
结合接口 default 方法 + 内部类委托，兼顾复用性与状态控制
default 方法适合无状态行为（如日志格式化、基础校验），但一旦涉及缓存、计数器、连接池等有状态逻辑，就必须用对象实例。这时内部类是理想代理：
- 定义接口 MetricsCollector，含 default 方法
logRequest()（仅打日志） - 但实际要统计 QPS、延迟分布，需维护
ConcurrentHashMap<String, AtomicLong> - 在外部类中定义 MetricsReporter extends AbstractMetricsCollector（抽象基类含共享字段），实现采集+上报闭环
- 外部类通过
metricsReporter.record("api/v1/order")触发带状态的完整链路
既享受接口多实现的灵活性，又保留内部类对私有资源的完全掌控力，比纯组合更内聚，比继承多个类更安全。
