空类（无字段、无方法）即使被继承，也不具备抽象类的语义和行为特征；抽象性由 abstract 关键字显式声明，而非由“空”或“被继承”隐式决定。
空类（无字段、无方法）即使被继承，也不具备抽象类的语义和行为特征；抽象性由 `abstract` 关键字显式声明，而非由“空”或“被继承”隐式决定。
在 Java 中，一个看似“空”的类——例如：
public class Vehicle {
}虽然不包含任何显式声明的字段或方法，但它绝不是抽象类。原因在于：抽象性是一种显式的语言契约，而非运行时或结构上的推断结果。
首先，Java 中的每个类（包括 Vehicle）都隐式继承自 Object，因此自动拥有 toString()、equals()、hashCode()、getClass() 等公共方法。这意味着它并非真正“空”，更不具备“未实现方法需强制子类覆盖”的抽象类核心特征。
其次，抽象类的本质在于定义可扩展的契约模板：它通过 abstract 修饰符明确声明自身不可实例化，并常包含抽象方法（无方法体，强制子类实现）或具体方法（提供复用逻辑）。而 Vehicle 类既未使用 abstract 关键字，也未声明任何抽象方法，编译器允许直接实例化：
立即学习“Java免费学习笔记（深入）”；
Vehicle v = new Vehicle(); // ✅ 合法，证明它不是抽象类
反之，若要将其设计为抽象类，必须显式声明：
public abstract class Vehicle { // ✅ 显式 abstract
public abstract void start(); // 可选：定义抽象行为
}
// new Vehicle(); // ❌ 编译错误：Cannot instantiate the type Vehicle值得注意的是，被继承本身并不赋予抽象性。普通类（如 String、ArrayList）同样广泛被继承，但它们是具体类，设计初衷就是可直接使用。是否抽象，只取决于是否用 abstract 修饰以及是否符合抽象类的语义职责——即：作为不完整的类型骨架，为多态和模板化设计服务。
? 补充提醒：
- 抽象类 ≠ 接口，但二者都用于定义契约；抽象类可含状态（字段）和部分实现，接口（尤其 Java 8+）则侧重纯行为契约；
- 现代设计更倾向优先使用组合与接口（如 Flyable、Drivable），而非深度继承链，以提升灵活性与可测试性；
- 工具如 IDE 或静态分析器（如 SonarQube）不会将空类标记为抽象类——因为 JVM 字节码中 ACC_ABSTRACT 标志位仅在源码显式声明 abstract 时才被设置。
总结：判断一个类是否为抽象类，唯一可靠依据是其源码中是否存在 abstract 修饰符，而非其内容是否为空、是否被继承、或是否缺少业务逻辑。保持这种清晰的语言契约意识，是写出健壮、可维护面向对象代码的基础。
