抽象类必须用abstract修饰且不能被实例化，本质是“不完整的类”，用于被继承而非创建对象；含抽象方法的类必须声明为abstract，抽象方法无方法体、不可用private/static/final修饰；子类非abstract则须实现全部抽象方法。
抽象类必须用 abstract 修饰，且不能被实例化
Java 中的抽象类本质是“不完整的类”，它存在的意义不是创建对象，而是被继承。如果你写了 new Animal() 这种代码，编译器会直接报错 Cannot instantiate the type Animal —— 不是因为语法写错了，而是语言设计上就禁止这么做。
常见错误是：在抽象类里写了构造方法，就误以为可以 new；或者子类没重写全部抽象方法，却用了 new SubClass()，结果编译失败但没意识到问题出在父类定义上。
- 抽象类可以有构造方法（供子类调用），但不能用
new直接实例化 - 抽象类可以包含普通方法、字段、静态方法、甚至
main方法 - 如果一个类里有至少一个
abstract方法，那这个类必须声明为abstract，否则编译不通过
abstract 方法没有方法体，子类必须 override（除非子类也声明为 abstract）
抽象方法只负责定义“做什么”，不关心“怎么做”。它像一张契约：子类要么履行（实现），要么明确表示“我也不确定，交给更下层去办”。所以它的签名后面直接跟分号，不能有 {}。
容易踩的坑是：在抽象方法里写了空的 {}，或者加了 final、private、static 修饰符——这些都会导致编译错误，因为和抽象方法的语义冲突。
立即学习“Java免费学习笔记（深入）”；
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
-
abstract方法不能是private（子类看不到，无法重写） -
abstract方法不能是static（静态方法属于类，不参与多态） -
abstract方法不能是final（final 方法禁止重写，和 abstract 矛盾） - 子类若非
abstract，就必须实现所有从父类继承来的abstract方法
模板方法模式依赖抽象类的结构控制力
模板方法模式的核心，就是把算法骨架放在抽象类里，把可变步骤抽成 abstract 方法。比如 prepareRecipe() 是 final 普通方法，里面调用 boilWater()、brew()、pourInCup()、addCondiments() —— 其中后两个是 abstract 的，由子类决定加糖还是加奶。
这里的关键不是“怎么写模式”，而是理解为什么必须用抽象类：只有 abstract 类才能强制子类实现某些行为，同时又允许复用固定逻辑。换成接口做不到这点（Java 8 前接口不能有方法体，Java 8 后默认方法不能是 final 或带状态）。
- 模板方法本身通常是
final的，防止子类篡改流程顺序 - 钩子方法（hook method）可以是空的
abstract或默认空实现的普通方法，让子类选择性覆盖 - 抽象类里的字段可以被所有子类共享或继承，接口做不到这点
抽象类 vs 接口：别只看“能定义什么”，要看“想约束什么”
Java 8 后接口也能有 default 和 static 方法，看起来和抽象类越来越像。但两者的定位根本不同：接口描述“能做什么”（能力契约），抽象类描述“是什么”（类型继承关系）。比如 Dog 是一种 Animal，这是 is-a 关系，适合用抽象类；而 Dog 可以 Swim，这是 can-do 关系，适合用接口。
实际项目里最容易翻车的是：为了省事，在抽象类里堆了一堆 default 方法，结果发现子类根本没法复用状态，或者需要多继承时卡死——Java 不支持类的多继承，但一个类可以实现多个接口。
- 抽象类支持构造器、成员变量、protected/package-private 方法，接口不行
- 抽象类只能单继承，接口可以多实现
- 如果只是行为扩展（如日志、监控、序列化），优先考虑接口；如果是领域建模中的共性类型（如各种
PaymentStrategy），抽象类更自然
abstract 就不是装饰，而是必要约束。 
