接口比继承更适合实现多态，因其解耦行为契约与实现细节，支持多维度能力组合、编译期类型安全、隐式实现及细粒度正交设计。
接口比继承更适合实现多态，根本原因在于它解耦了「行为契约」和「实现细节」——你不需要让类在继承树里站队，只要承诺能做某件事，就能参与多态调度。
Java 中 interface 与 extends 在多态中的角色差异
Java 不支持多继承，但一个类可以实现多个 interface。这意味着你可以让 Dog 同时具备 Runnable、Barkable、Serializable 等不同维度的能力，而这些能力在运行时都能通过统一的引用类型触发多态行为：
Runnable r = new Dog(); Barkable b = new Dog(); r.run(); // 多态调用 b.bark(); // 多态调用
如果全靠 extends，Dog 就只能继承自 Animal（或别的单一父类），无法再“同时是”Machine 或 NetworkNode —— 但现实中，一个无人机对象完全可能既是 Drivable 又是 Flyable 又是 Loggable。
ClassCastException 和空方法体是继承式多态的常见陷阱
为强行复用而设计的抽象父类，常导致子类被迫实现无意义的方法，或者在运行时因类型强转失败抛出 ClassCastException：
- 抽象类
Vehicle定义了fly()，但Car子类只能抛UnsupportedOperationException - 调用方写
((Airplane) vehicle).fly()，一旦传入Car实例就崩溃 - 而用
Flyable接口，只有真正实现了它的类才能被赋值给Flyable引用，编译期就过滤掉了不合法组合
Go 的接口隐式实现进一步说明问题本质
Go 根本没有 implements 关键字，只要结构体有对应方法签名，就自动满足接口。这反向印证：多态的关键不是“我声明我要继承谁”，而是“我恰好能响应这个消息”。例如：
type Speaker interface {
Speak() string
}
type Person struct{}
func (p Person) Speak() string { return "Hello" }
type Robot struct{}
func (r Robot) Speak() string { return "Beep boop" }
// 无需显式声明，Person 和 Robot 都可直接用于 []Speaker
这种设计把多态的决定权从定义侧（类声明时）移到使用侧（函数参数、切片类型），更贴近“按需组合”的真实需求。
真正容易被忽略的是：接口定义的粒度。一个叫 Service 的大接口，和拆成 Reader、Writer、Closer，对多态的灵活性影响极大——越小、越正交的接口，越容易被不同类独立实现，也越不容易逼人写出 throw new UnsupportedOperationException()。
