Java接口多继承旨在按能力维度拆分契约，如Payable、Refundable；需显式解决default方法冲突；常量应加前缀或显式限定；标记接口（如Serializable）须与行为接口解耦。
Java 接口的多继承不是为了堆砌功能，而是为了清晰表达“一个类同时具备多种可组合的能力”。关键在于按能力维度拆分，而不是按业务实体或模块来硬凑。
按能力契约而非业务实体划分接口
接口应描述“能做什么”，比如 Payable（支持支付）、Refundable（支持退款）、Loggable（支持操作留痕），而不是 OrderInterface 或 UserInterface 这类包裹大量无关行为的大而全接口。前者可自由组合：class PremiumOrder implements Payable, Refundable, Loggable；后者容易导致实现类被迫实现无用方法，违背接口隔离原则。
冲突默认方法必须显式解决
当多个父接口提供同名 default 方法时，子接口不能含糊继承。必须重写该方法，并明确选择调用路径或提供新逻辑：
- 若语义一致（如两个接口的
log()都是记录基础操作），可统一委托给某一方：ParentA.super.log() - 若语义不同（如
Payment.log()记交易，Audit.log()记合规），应在子接口中重写为有意义的聚合行为，例如先记交易再触发审计检查 - 避免在实现类里重复解决——冲突应在接口层收敛，实现类只专注业务逻辑
常量命名需带前缀或限定访问
多个父接口若定义同名常量（如都叫 TIMEOUT），直接使用会编译报错。推荐做法：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 接口内常量统一加业务前缀：
PAY_TIMEOUT、REFUND_TIMEOUT - 必须复用同名常量时，在使用处显式指定接口：
PaymentConfig.TIMEOUT，不依赖导入别名或静态导入 - 优先用枚举替代分散常量，尤其涉及状态码、类型标识等场景
标记接口与能力接口分层设计
像 Serializable、Cloneable 这类无方法的标记接口，应与含行为的方法接口解耦。例如：
- 定义
Exportable（含export()方法）表达导出能力 - 另定义
SecureExportable extends Exportable，叠加安全约束（如要求加密） - 若某类还需序列化，直接
implements Exportable, Serializable即可，不把序列化逻辑塞进Exportable
这样既保持各能力正交，又让实现类能按需装配，不复杂但容易忽略细节。
