抽象方法是父类声明、子类必须实现的契约，不可有方法体，不能为private或static；编译器强制要求含抽象方法的类声明为abstract，非abstract子类须覆盖所有继承的抽象方法。
抽象方法必须被子类实现，否则编译直接报错
抽象方法本质是契约：父类不提供逻辑，只声明“这里必须有实现”。Java 编译器会强制检查——只要类里有 abstract 方法，这个类就必须声明为 abstract；而任何非 abstract 的子类，必须覆盖所有继承来的抽象方法。
常见错误现象：java.lang.AbstractMethodError 不是在编译期出现的，而是在运行时调用未真正实现的抽象方法时抛出，说明编译通过了但子类实际漏写了某个重写（比如签名拼错、参数类型不一致、忘了加 @Override）。
- 抽象方法不能有方法体，连
{}都不能写，否则编译失败 - 抽象方法不能是
private或static——前者子类不可见，后者无法被重写 - 接口里的
default方法和static方法不是抽象方法，不要混淆
模板方法模式靠抽象方法留钩子，不是靠 if-else 控制流程
模板方法的核心是把算法骨架写在 final 方法里，把可变部分抽成抽象方法，让子类决定细节。它不是用条件分支去切换逻辑，而是靠多态分发。
典型误用：在模板方法里写一堆 if (type == A) { ... } else if (type == B) { ... }，这等于把扩展点硬编码死了，违背了开闭原则。
立即学习“Java免费学习笔记（深入）”；
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 模板方法本身通常用
final修饰，防止子类篡改执行顺序 - 抽象方法命名要体现意图，比如
doValidate()、buildResponse()，而不是step1()、step2() - 如果某步逻辑有默认行为，可以定义成
protected普通方法，子类选择是否重写，比强求抽象更灵活
抽象类里混用抽象方法和具体方法，小心初始化顺序陷阱
抽象类也是类，构造函数照常执行。但子类构造器第一行默认调 super()，意味着抽象类构造器会在子类字段初始化前运行——这时候若抽象方法在构造器中被调用（比如通过钩子回调），而子类字段还没初始化，就可能读到 null 或默认值。
这种 bug 很隐蔽，日志里看不到异常，只有业务逻辑出错才暴露。
- 绝对避免在抽象类构造器中调用
abstract方法（JVM 允许但语义危险） - 如果需要预加载或校验，把触发时机往后挪，比如放到第一个公开的业务方法入口里
- 抽象类的字段尽量设为
final，或明确文档注明“子类构造完成前不可依赖”
抽象方法不等于接口，选错会导致后续重构成本飙升
抽象类适合“is-a”关系且需共享状态或逻辑；接口适合“can-do”能力声明。一旦用抽象类定义了抽象方法，子类就被绑定到单继承树上——后面想再实现另一个能力（比如 Serializable 是小事，但 Comparable 或自定义事件接口）就得靠组合或额外包装。
更麻烦的是：如果抽象类已经发布为公共 API（比如 SDK 中的基类），往里加新抽象方法等于破坏二进制兼容性，所有子类立刻编译失败。
- 优先考虑接口 + 默认方法，除非真需要共享字段或 protected 辅助逻辑
- 抽象类加新抽象方法前，先评估是否能用
default方法+注释警告替代 - 如果已有大量子类，新增抽象方法不如新增一个新抽象类，让老子类继续继承旧的，新需求走新分支
抽象方法看着简单，但每加一个，都是在给继承链打一个死结。留钩子容易，解钩子很难。
