抽象类该有构造函数，且通常必须有；它不能是private，推荐用protected修饰，子类构造器需显式调用super(...)。
抽象类该不该有构造函数？
该有，而且通常必须有。抽象类虽然不能直接实例化，但它的子类在创建对象时，一定会调用抽象父类的构造函数——这是 Java 初始化链的硬性规则。
常见错误现象：java.lang.NullPointerException 在子类刚 new 出来就抛出，往往是因为抽象类里依赖的 init() 方法没被调用，而你误以为“抽象类不 new 就不用管构造逻辑”。
- 抽象类的构造函数不能是
private（否则子类无法访问，编译失败） - 推荐用
protected修饰，既防止外部直接调用，又允许子类继承调用 - 如果抽象类有带参构造函数，子类构造器第一行必须显式写
super(...)，否则编译报错：Implicit super constructor XXX() is undefined
abstract 方法和 default 方法混用时要注意什么？
Java 8+ 允许在抽象类中定义 default 方法，但它和接口里的 default 行为不完全等价：抽象类中的 default 方法可以访问 protected 成员、调用 abstract 方法，甚至操作 this 的状态。
容易踩的坑：default 方法里调用了尚未被子类实现的 abstract 方法，而子类又在自己的构造过程中触发了该 default 方法——此时 this 是半初始化状态，可能读到字段默认值（如 null 或 0），引发诡异 bug。
立即学习“Java免费学习笔记（深入）”；
- 避免在构造器或
init()链中调用任何可能被重写的abstract或default方法 -
default方法适合封装“稳定流程 + 可插拔步骤”，比如process()调用validate()（abstract）→doWork()（default）→cleanup()（abstract） - 别为了省几行代码，把本该由子类决定的逻辑塞进
default方法里
什么时候该用 abstract class，而不是 interface？
核心判断点就一个：是否需要共享**可变状态**或**非 public 成员**。
使用场景对比：
- 要定义
protected String token并让所有子类复用其生命周期管理？→ 抽象类 - 只是约定一组行为契约，且所有方法都该是
public？→ 接口更轻量 - 需要提供带实现的模板方法（
final void execute() { before(); doAction(); after(); }）？→ 抽象类唯一能做的 - 想让类同时继承行为和状态，又得实现多个能力？→ 抽象类 + 接口组合（抽象类负责状态和骨架，接口负责能力声明）
性能影响几乎可忽略，但兼容性上注意：Java 8 前的抽象类没法加新方法而不破坏子类；现在虽可加 default，但若已有子类重写了同签名方法，就会覆盖抽象类的 default 实现——这点常被忽略。
子类 override 抽象方法时，访问修饰符能改吗？
能改，但只能**扩大**，不能缩小。子类重写后的方法访问级别必须 ≥ 抽象父类中声明的级别。
例如：抽象类里声明 protected abstract void parse();，子类可以写 public void parse()，但不能写 private void parse() 或保留 protected 却删掉 abstract 关键字却不实现——后者会直接编译失败。
- 如果抽象方法是
public，子类也必须是public（Java 规定，不可降级） - 别依赖 IDE 自动生成的 override 提示就完事，检查下生成的方法签名是否意外加了
final或改了返回类型 - 返回类型支持协变（covariant return）：父类声明
abstract Animal getPet();，子类可写@Override Dog getPet()
最易被忽略的是：抽象类本身被 final 修饰（虽然语法允许，但彻底失去继承意义），或者子类忘了加 @Override 注解导致静默重载而非重写——这种 bug 往往要到运行时才暴露。
