Java类不能extends多个类，因编译器无法解决方法或字段歧义，如B、C均有void start()时A调用无从选择；而接口可多实现，因其仅声明契约、无状态，实现类统一提供方法即可。
为什么 Java 类不能 extends 多个类
因为编译器无法解决方法或字段的歧义。比如 class A extends B, C 中，B 和 C 都定义了 void start()，A 调用 start() 时该走哪个？JVM 没法自动选，也不该替你决定。这不是语法限制，而是语义冲突——“是一个 B”和“是一个 C”在领域模型里本身就可能矛盾。
常见错误现象包括：
– 编译直接报错 error: '{' expected 或 error: class X is already defined（其实是 extends 后多写了类）
– IDE 提示 “Only one class can be extended”
– 把接口误写成 extends InterfaceA, InterfaceB，实际该用 implements
为什么接口可以 implements 多个，甚至 interface 可以 extends 多个
接口不带状态、不带构造逻辑，只声明契约。即使 InterfaceA 和 InterfaceB 都定义了 void run()，实现类只需提供一份 run() 实现即可，调用时永远走实现类的版本，不存在“选哪个父类”的问题。
但要注意：如果两个接口定义了同名但不同返回类型的 run()，比如一个返回 void，另一个返回 boolean，那实现类会编译失败——签名冲突，不是歧义，是根本无法共存。
立即学习“Java免费学习笔记（深入）”；
使用场景中容易忽略的点：
– 接口间继承（如 interface SmartDevice extends Runnable, Serializable）是合法的，且可叠加 default 方法
– 实现类若重写某个 default 方法，它就覆盖所有来源的同签名 default 行为
– 接口中的 public static final 字段若重名，实现类不能直接引用，否则报 reference to X is ambiguous
default 方法怎么影响多实现的协作逻辑
Java 8 引入 default 方法，本质是给接口“加一点实现”，但它不是为了替代继承，而是为演进留缝。比如 JDK 在 Collection 加 stream()，所有已存在的实现类立刻可用，不用改继承链。
但滥用会破坏职责边界：
– 如果多个接口的 default 方法都试图初始化同一资源（如日志器、连接池），实现类没做协调，就可能重复初始化或状态错乱
– 一个类实现 Loggable 和 Cacheable，两者 default 方法都含 init()，但执行顺序不确定，this 尚未完全构造完成时就被调用，容易 NPE
– 建议：default 方法只做轻量委托，重逻辑仍交给实现类或组合对象
什么时候该用抽象类，而不是堆砌一堆接口
当多个子类共享字段、构造流程、模板方法或受保护的工具逻辑时，抽象类比接口更合适。比如 AbstractVehicle 统一封装 fuelLevel、startEngine() 模板、checkSafety() 钩子，子类只填空 drive()。
反模式示例：
– 为每个功能建接口： HasEngine、HasWheels、HasBrakes，再让 Car 实现全部——这混淆了“能力”和“组成部分”
– 接口里塞满 default 方法，甚至用 static { ... } 块初始化全局状态，导致测试隔离困难
– 所有实现类都要复制粘贴相同字段和 getter/setter，说明它们本就该继承同一个基类
真正关键的分界线在于：是否需要共享**可变状态**或**受控的初始化顺序**。有，就用抽象类；没有，优先接口。
