Java接口多继承是原生支持的行为契约组合机制，通过extends聚合多个接口形成统一能力契约，避免重复声明并简化调用方依赖。
Java 中接口的多继承不是“绕过限制的技巧”，而是语言原生支持的行为契约组合机制。它不传递状态、不管理生命周期，只明确“这个对象必须能做什么”。实战中真正有价值的做法，是用接口多继承把分散的业务规范收拢成一个清晰的顶层契约，再让具体类统一实现——既避免重复声明，又让调用方只需关注一个接口类型。
用 extends 组合多个业务接口，形成统一能力契约
比如订单系统里有支付、通知、风控三类独立规范，各自定义在不同模块：
-
Payable：声明
pay()、refund() -
Notifiable：声明
sendSms()、sendEmail() -
RiskCheckable：声明
verify()、blockIfRisky()
你可以定义一个聚合接口：
interface OrderService extends Payable, Notifiable, RiskCheckable { }
后续所有订单服务实现类（如 OnlineOrderService、O2OOrderService）只需 implements OrderService，就天然承诺履行全部九个方法。调用方也只需声明 OrderService service，无需关心背后混入了几个接口。
同名 default 方法冲突必须显式处理，别跳过编译报错
当多个父接口都提供了同签名的 default 方法（例如 logOperation()），Java 编译器会强制你在实现类中重写该方法。这不是负担，而是设计信号：
- 直接转发某一方（
A.super.logOperation()）仅适用于逻辑完全一致的场景 - 更常见的是合并行为：先记录基础日志，再加业务上下文，最后触发监控埋点
- 如果两个
default方法都修改数据库或发消息，说明接口职责已越界，该拆分或重构
这类冲突暴露的是契约设计问题，解决它比绕过它更有长期价值。
接口变量统一靠常量继承，但注意命名冲突与覆盖逻辑
接口中定义的字段自动是 public static final，会被子接口继承。例如：
interface A { int TIMEOUT = 3000; }
interface B { int TIMEOUT = 5000; }
interface C extends A, B { int TIMEOUT = 8000; }
此时 C.TIMEOUT 是 8000；若某类只 implements A, B，则直接访问 TIMEOUT 会编译失败（歧义）。所以：
- 聚合接口中可重新定义关键常量，作为唯一可信源
- 避免在多个基础接口中定义同名常量，尤其像
MAX_RETRY、DEFAULT_PAGE_SIZE这类易重名项 - 业务常量建议集中到配置类或枚举，接口只保留行为相关常量（如协议码、事件类型）
统一变量类型的关键在于向上转型，而非字段注入
有人想通过“在类里持有一堆接口字段”来模拟多继承，比如：
class OrderProcessor {
private Payable payer;
private Notifiable notifier;
private RiskCheckable risker;
}
这容易引发空指针和初始化顺序混乱。正确做法是让 OrderProcessor 自身 implements OrderService，然后对外暴露单一类型：
- 外部调用统一用
OrderService类型接收 - 内部逻辑按需调用
this.pay()、this.sendSms()等，语义清晰 - 测试时可直接 mock
OrderService，不用组装三个依赖
这样变量统一不是靠字段聚合，而是靠契约归一和类型抽象。
