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