abstract类必须用abstract关键字声明且不可实例化，核心是表达“类不完整、须由子类补全”；含abstract方法则类必为abstract，反之不必然；abstract方法无方法体，仅public或protected合法；子类须实现全部abstract方法，否则自身也须声明为abstract；结合final模板方法可控制流程骨架。
abstract 类必须用 abstract 关键字声明，且不能被实例化
Java 中 abstract 类的核心作用不是“提供模板”，而是明确表达“这个类不完整，必须由子类补全”。一旦类中包含至少一个 abstract 方法，整个类就必须用 abstract 修饰；反过来，abstract 类可以没有抽象方法（比如只做禁止实例化的约束），但这种用法极少，也容易误导团队。
常见错误是漏写 abstract 关键字却定义了 abstract 方法，编译器会直接报错：error: abstract method in non-abstract class。还有一种隐蔽错误：把 abstract 类当成普通基类，在其他地方写了 new AbstractService()——这会导致编译失败，因为 JVM 不允许实例化 abstract 类。
abstract 方法不能有方法体，且访问修饰符只能是 public 或 protected
abstract 方法本质是契约声明，只规定签名，不提供实现。所以它的方法体必须省略（连 {} 都不能有），否则编译报错：error: abstract method cannot have a body。
访问修饰符受限是因为：private 方法无法被子类继承和重写；默认包级访问（package-private）在跨包继承时会失效；而 final 和 static 与 abstract 语义冲突（前者禁止重写，后者强制重写）。所以合法组合只有：public abstract void doBusiness(); 或 protected abstract String buildKey();
- 如果业务逻辑必须对外暴露，用
public abstract - 如果只是子类内部协作用（比如模板方法里调用的钩子），用
protected abstract - 别写
private abstract、static abstract、final abstract——语法不通，IDE 会立刻标红
子类继承 abstract 类时，必须实现所有 abstract 方法，除非子类也声明为 abstract
这是强制契约落地的关键环节。编译器会在子类编译时检查：是否每个 abstract 方法都有对应签名的非 abstract 实现（包括 @Override 注解不是必须，但强烈建议加上，避免拼写错误导致隐式继承而非重写）。
常见疏漏点：
- 方法签名看似一样，但参数类型用了不同包的同名类（如
java.util.Listvs 自定义List），导致实际未覆盖 - 返回类型不协变（例如父类声明
abstract Object getValue();，子类写String getValue()是合法的，但写int getValue()就不行——基本类型不支持协变） - 子类加了
throws检查异常，但比父类声明的范围更宽（如父类抛IOException，子类抛Exception），编译不通过
结合 template method 模式才能真正控制业务流程骨架
光靠 abstract 方法只能强制“做什么”，没法约束“什么时候做、顺序如何”。这时候需要非 abstract 的模板方法——它定义流程骨架，把可变部分委托给 abstract 方法。
例如：
public abstract class OrderProcessor {
// 模板方法：不可重写，控制流程
public final void process() {
validate();
calculateFee();
persist();
notifyUser(); // 这个可选，子类可空实现
}
// 强制子类实现
protected abstract void validate();
protected abstract void calculateFee();
protected abstract void persist();
// 可选钩子，默认空实现
protected void notifyUser() {}
}
这样既保证核心步骤不被跳过，又把具体实现细节下放。容易忽略的是：模板方法本身应加 final，否则子类可能绕过流程；钩子方法（如 notifyUser）要用空实现而非 abstract，否则所有子类都得填无意义的空方法体。
抽象类的真正复杂点不在语法，而在设计分寸：哪些该抽象，哪些该默认，哪些该 final。过度抽象会让子类负担过重，抽象不足又失去约束力。每次加一个 abstract 方法前，先问一句：这个逻辑真的每种子类都完全不同，且无法提供安全的默认行为吗？
