抽象类可被继承并含构造方法、成员变量和具体方法，支持状态共享与初始化逻辑；接口仅定义行为契约，无状态、无构造器，Java 8 后虽有 default/static 方法但仍无法持有实例状态。
抽象类不能被实例化，但可以有构造方法和成员变量
抽象类用 abstract class 声明，它允许包含具体方法、protected 或 private 成员变量、静态字段，甚至带参数的构造方法。这点和接口完全不同——接口里不能有构造方法，所有字段默认是 public static final，所有方法默认是 public abstract（Java 8 后可加 default 和 static 方法，但仍不能有实例状态）。
实际写代码时，如果你需要子类共享初始化逻辑（比如连接数据库前统一读取配置），抽象类的构造方法就很有用；而接口做不到这点。
- 抽象类中可定义
protected String baseUrl;，子类直接继承并复用 - 接口中写
String baseUrl = "https://api.example.com";，本质是public static final，不可被子类“继承状态”，只能引用 - 抽象类的构造方法会被子类
super()显式或隐式调用；接口无此机制
一个类只能继承一个抽象类，但能实现多个接口
这是 Java 单继承机制决定的硬限制。当你设计模块间解耦或能力组合时，这个差异直接影响架构选择。
比如你有一个 PaymentService 类，既要支持「退款」（Refundable 接口），又要支持「对账」（Reconcilable 接口），还要复用「HTTP 请求模板」（HttpBaseClient 抽象类），那就必须：继承 HttpBaseClient + 实现 Refundable 和 Reconcilable。
立即学习“Java免费学习笔记（深入）”；
本文档主要讲述的是Android JNI开发入门与提高；JNI在Android系统中有着广泛的应用。Android系统底层都是C/C++实现的，上层提供的API都是Java的，Java通过JNI调用底层的实现。比如：Android API多媒体接口MediaPlayer类，其实底层通过JNI调用libmedia库。希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
- 如果把 HTTP 模板也做成接口，就无法在其中放
protected HttpClient client;这样的可变成员 - 若强行让多个抽象类提供不同能力，会触发编译错误：
java: java.lang.Object is already defined in this compilation unit - 接口适合定义“能做什么”（what），抽象类更适合定义“是什么+怎么起步”（what + how to start）
Java 8+ 接口中的 default 方法不是万能的替代方案
default 方法确实缓解了接口升级的兼容性问题，但它不能访问实现类的私有字段，也不能调用 super 父类方法，更无法持有状态。一旦你在 default 方法里试图操作 this.name，而实现类没暴露该字段，就会编译失败。
public interface Loggable {
String getId(); // 必须由实现类提供
default void logStart() {
System.out.println("Starting task: " + getId()); // OK：调用抽象方法
}
default void logWithCounter() {
// 编译错误！接口里没有 counter 字段
// counter++;
}
}
-
default方法适合通用行为模板（如日志格式、空值校验），不适合需要维护内部状态的逻辑 - 如果多个接口提供了同名
default方法，实现类必须显式重写，否则编译报错：class inherits unrelated defaults for method - 抽象类里的普通方法天然可访问
this的所有非私有成员，包括子类继承来的字段
选抽象类还是接口？看是否需要共享状态或强制初始化流程
别纠结“哪个更新潮”，重点看模型本质。如果一组类天然属于同一类型（比如 Animal 下的 Dog、Cat），且共用资源（如共享的 healthPoint、统一的 init() 流程），就用抽象类；如果只是临时赋予某种能力（如 Serializable、Comparable、自定义的 Exportable），就用接口。
容易被忽略的一点是：抽象类可以成为“模板方法模式”的载体，把算法骨架写死，只留钩子给子类实现；而接口哪怕加了 default 方法，也无法控制调用顺序或封装步骤间的依赖。
- 抽象类中可写：
final void execute() { prepare(); doWork(); cleanup(); }，子类只能改doWork() - 接口做不到
final方法，也无法阻止实现类乱序调用prepare()和cleanup() - Spring 的
JdbcDaoSupport是抽象类，因为它要持有一个JdbcTemplate实例并确保初始化；而InitializingBean是接口，只声明“我准备好了”，不参与状态管理
