Java不允许类多继承但允许多实现接口，因JVM方法分派依赖单一继承链以避免菱形继承歧义，而接口仅定义契约、不破坏vtable结构；默认方法冲突需显式重写，多实现提供正交能力插槽，优于组合代理。
Java 为什么不允许类多继承，但允许实现多个接口
因为 JVM 的方法分派机制依赖明确的继承链，而多继承会引发菱形继承问题（比如两个父类都有同名 toString()，子类调用时无法确定走哪条路径）。接口不包含状态和具体实现（默认方法是例外，但有严格约束），只定义契约，所以允许多实现不会破坏虚方法表（vtable）结构。
这不是“妥协”，而是设计取舍：用编译期契约检查 + 运行期动态绑定，换来了清晰的职责分离。
多实现接口如何实际绕过单继承限制
当一个类需要复用多个维度的行为（比如既要可序列化、又要可比较、还要能被 JSON 序列化），又不能继承多个类时，接口就是最轻量的“能力插槽”。
-
class Order implements Serializable, Comparable—— 三个能力互不干扰，各自由不同模块定义, JsonSerializable - 每个接口的默认方法（如
Comparator.naturalOrder()）可直接复用，无需在每个子类里重写 - 如果某能力需定制逻辑（如自定义比较），只需重写对应接口方法，不影响其他接口行为
容易踩的坑：默认方法冲突与 diamond problem 变体
Java 8+ 引入默认方法后，多实现可能触发冲突：当两个接口都提供了同签名的默认方法，编译器会报错 classes Order and JsonSerializable both define a default method toString()。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 必须在实现类中显式重写该方法，哪怕只是调用其中一个
super.toString() - 不能靠“先实现哪个接口”来决定优先级——顺序无关，编译器强制你表态
- 若接口 A extends B，且两者都有默认方法，A 的默认方法会覆盖 B 的，这属于继承规则，不是冲突
替代方案对比：组合 vs 多实现 vs 代理类
有人会说“用组合也能解耦”，比如让 Order 持有 JsonSerializer 实例。但这带来额外对象创建、间接调用开销，且调用方需知道内部结构（order.getSerializer().toJson()）。
- 多实现让能力直接暴露为类型：你可以把
Order当作JsonSerializable传给任意接受该接口的方法 - IDE 和静态分析工具能基于接口做准确推导（比如自动补全
compareTo()） - 真正难的是接口粒度——定义太粗（如
Service）会导致实现类被迫实现一堆无关方法；太细（如CanExportToCsv）又泛滥成灾
接口不是越多越好，关键在是否形成稳定、正交、可测试的契约边界。这点比语法支持更重要，也更常被忽略。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
