判断类继承关系首选instanceof（运行时，null返回false）；编译期检查用extends/super；完整继承链需循环getSuperclass()；isAssignableFrom用于类型兼容性预检；接口继承需递归getInterfaces()；枚举和数组类不可继承；抽象类适合共享状态与实现，接口适合多继承契约；继承过深（>3层）易致维护困难；泛型运行时被擦除，需ParameterizedType获取实参。
Java中如何判断一个类是否属于某个继承链
直接用 instanceof 最快，但要注意它只在运行时生效，且对 null 返回 false。如果需要编译期检查或泛型约束，得靠 extends 或 super 边界声明。
常见错误是误以为 getClass().getSuperclass() 能拿到完整继承路径——它只返回直接父类，要遍历整个树得循环调用 getSuperclass() 直到返回 null。
-
Class.isAssignableFrom(Class)更灵活：比如Number.class.isAssignableFrom(Integer.class)返回true，适合做类型兼容性预检 - 反射获取接口要用
getInterfaces()，它不包含父接口，想查完整接口继承需递归处理 - 枚举类和数组类不能被继承，
getSuperclass()对它们返回java.lang.Enum或java.lang.Object，但实际无法写extends
什么时候该用抽象类而不是接口
核心看是否要共享状态或强制子类复用实现逻辑。Java 8 后接口能有 default 方法，但无法定义非静态字段、构造器，也不能有 protected 成员。
典型场景：AbstractList 封装了 size()、isEmpty() 等共用逻辑，并持有一个 modCount 字段用于快速失败；而 List 接口只定义契约，不带状态。
- 需要构造器参数传递初始化逻辑 → 只能选抽象类
- 要限制子类必须继承某个具体实现（如日志、缓存模板）→ 抽象类更合适
- 多继承需求强烈（比如既要可序列化又要可比较）→ 接口更自由，抽象类只能单继承
避免继承树过深的三个信号
超过三层继承（A → B → C → D）往往意味着职责混淆或设计僵化。JVM 本身不限制深度，但维护成本会指数上升。
典型表现：toString() 输出全是 com.xxx.yyy.zzz.SomeImpl@12345，调试时根本看不出实际类型；或者改一个 protected 方法，十几个子类单元测试全挂。
- 子类重写方法里频繁调用
super.xxx()，且逻辑嵌套超过两层 → 考虑提取为组合策略 - 存在大量
if (this instanceof X) { ... }类型分支 → 违反开闭原则，应转为多态分发 - 文档里写“请确保子类在重写
init()后再调用super.init()” → 这是模板方法模式误用，应把钩子方法设计得更安全
// 错误示例：继承过深 + 隐式调用约定
abstract class Vehicle {
protected void start() { /* ... */ }
}
class Car extends Vehicle {
@Override protected void start() { super.start(); /* ... */ }
}
class ElectricCar extends Car {
@Override protected void start() { super.start(); /* ... */ }
}
// 正确方向：把可变部分抽成 Strategy 接口，Vehicle 持有它
泛型与继承混合时的类型擦除陷阱
泛型信息在运行时被擦除，所以 List 和 List 的 getClass() 结果完全相同，都是 ArrayList.class。这导致无法靠反射做泛型类型校验。
常见坑：用 Class.isAssignableFrom() 判断泛型子类时失效，比如 List.class.isAssignableFrom(ArrayList.class) 是 true，但你没法知道这个 ArrayList 原本声明的是 。
- 运行时获取泛型实参要用
ParameterizedType，仅适用于字段、方法返回值、父类声明等「静态可见」位置 -
new ArrayList才能拿到带泛型的父类信息() {{ add("x"); }}.getClass().getGenericSuperclass() - 不要在
catch块里依赖泛型类型做分支，JVM 看不到泛型差异
继承树不是越深越好，也不是越扁越好。真正难的是在「复用」
