接口多继承应聚焦正交职责的契约组合，按能力维度拆分如paymentcapable、cancellationcapable等，orderbehavior仅聚合不新增方法；接口无状态、无变量逻辑，依赖注入实现策略；扁平化继承避免隐式义务；default方法仅用于无状态通用行为。
接口多继承不是为了拼凑功能，而是把正交、可独立演化的职责打包成一个语义清晰的契约组合。关键在于让每个接口只表达“能做什么”，不掺杂状态、配置或实现细节。
按能力维度拆分基础接口
一个业务实体常具备多个互不干扰的能力维度，比如订单要支持支付、取消、物流追踪、通知回调——这些不是上下级关系，而是并列契约。
- 定义 PaymentCapable：只含
pay()、refund() - 定义 CancellationCapable：只含
cancel()、reasonForCancellation() - 定义 TrackingCapable：只含
getTrackingNumber()、checkStatus() - 再声明 OrderBehavior extends PaymentCapable, CancellationCapable, TrackingCapable——它不新增方法，仅提供统一命名入口
这样调用方可以按需依赖具体接口（如物流服务只需 TrackingCapable），实现类也可选择性实现（如线下订单不实现 PaymentCapable），避免空方法或强制履约。
用组合落地变量逻辑，接口保持无状态
接口不能有字段，也不该封装重试次数、超时阈值、日志级别等变量逻辑。这些必须由实现类通过构造注入或策略委托完成。
- 在
OnlineOrder中声明private final RetryPolicy retryPolicy;，通过构造函数传入 - 定义 RetryStrategy 接口，让
HttpRetryer实现它，再由支付实现类持有并调用 - 避免在接口里塞 default 方法模拟配置逻辑，否则会模糊契约边界、增加测试负担
扁平化继承结构，拒绝隐式义务链
接口继承链越深，实现类承担的间接契约越多，容易遗漏方法、难以追溯责任。应优先扁平设计。
- 基础能力接口（如
Loggable、Serializable）直接被业务接口继承，不设中间层 - 若发现
A和B总被同一类同时实现，说明它们本就属于同一领域契约，考虑合并为新接口 - 避免
X extends Y, Z; Y extends U, V这类嵌套，改用显式多继承（X extends Y, Z, U, V）更直观可控
default 方法仅用于无状态通用行为
Java 8+ 的 default 方法适合封装与状态无关、所有实现都可复用的逻辑，比如日志埋点模板、参数校验骨架。
- 例如
Loggable接口提供default void logInfo(String msg)，内部调用统一 Logger 实例 - 若两个父接口有同名 default 方法，子接口必须显式重写，否则实现类编译失败；这是设计上的强制提醒，不是缺陷
- 禁止用 default 方法封装需访问私有字段或依赖外部配置的逻辑——那已超出契约范畴
