继承使子类编译期获得父类非私有成员，支持运行时多态；但易致紧耦合，应优先组合与接口实现，仅当满足稳定“is-a”关系时使用。
继承让子类直接获得父类的非私有成员
Java 中 extends 的本质，是让子类在编译期就“复制”了父类的 public 和 protected 字段、方法（不包括构造器），以及默认访问权限下同包可见的成员。这不是运行时动态挂载，而是编译器生成的符号引用绑定。
这意味着：
class Animal {
protected String name;
public void eat() { System.out.println(name + " is eating"); }
}
class Dog extends Animal {
public void bark() { System.out.println(name + " is barking"); }
}中，Dog 实例能直接访问 name 并调用 eat()，因为 JVM 在加载 Dog 类时已确认其继承链并验证了访问权限。
- 私有字段（
private）不会被继承，子类不可见，也不能通过super.xxx访问——除非父类提供了public/protected的 getter/setter - 构造器不会被继承，但子类构造器必须显式或隐式调用
super()，否则编译失败 - 静态成员属于类本身，子类“可访问”但不是“继承”；修改
static字段会影响所有类共享的值，和继承无关
继承是实现运行时多态的前提
没有继承（或接口实现），instanceof 判断、向上转型、方法重写（@Override）都无从谈起。JVM 依靠类的继承关系构建虚方法表（vtable），才能在运行时根据实际对象类型分派方法调用。
例如：
List若animals = new ArrayList<>(); animals.add(new Dog()); animals.add(new Cat()); for (Animal a : animals) { a.makeSound(); // 运行时才决定调用 Dog.makeSound() 还是 Cat.makeSound() }
Dog 和 Cat 没继承自 Animal，这段代码连编译都过不了——泛型约束、循环变量类型、方法调用合法性全依赖继承建立的类型兼容性。
- 重写（override）必须满足：方法名、参数列表、返回类型（协变允许子类型）一致，且访问权限不能更严格
-
final方法不能被重写，final类不能被继承，这是 JVM 强制的契约边界 - 字段不支持多态：即使子类定义了同名字段，访问时仍按引用类型决定——
Animal a = new Dog(); a.name取的是Animal的name，不是Dog的
继承不是代码复用的万能解，容易导致紧耦合
很多人误以为“复用代码 = 用 extends”，结果写出深度继承树，比如 Vehicle → Car → ElectricCar → TeslaModel3。一旦中间某层语义变化（如 Car 新增强制油箱字段），所有下游子类都要改。
真正安全的复用优先级应是：组合 > 接口实现 > 继承。比如把“能导航”抽成 Navigator 接口，让 Car 和 Smartphone 都实现它，比让后者继承前者合理得多。
立即学习“Java免费学习笔记（深入）”；
- 继承暴露父类实现细节，子类被迫依赖其内部逻辑；组合则通过接口隔离，父类换实现不影响子类
- Java 不支持多继承，但一个类可实现多个接口，组合+接口能模拟更灵活的关系
- 单元测试时，继承链越长，mock 越困难；组合对象可单独测试，再注入到宿主类中
什么时候该用继承？看是否满足“is-a”且语义稳定
判断标准不是“有没有共用代码”，而是“子类是不是父类的一种”。比如 ArrayList 是一种 List，IOException 是一种 Exception——这些关系在 JDK 设计时就被固化，极少变动。
反例：Stack 继承 Vector（旧版 JDK）曾被诟病，因为栈不是向量，只是“用向量实现栈操作”，后来 Java 提供 Deque 接口 + ArrayDeque 实现，更准确反映“栈是一种双端队列”的语义。
- 如果父类是
final、private构造、或文档明确写“designed for extension”，才放心继承 - 业务代码中，优先用
abstract class定义模板逻辑（如统一日志、事务模板），再由具体子类填充abstract方法 - 避免为复用工具方法而继承——那些本该是
static工具类或default接口方法
