抽象类能有构造方法，接口不能；抽象类用于“is-a”关系和状态共享，接口用于“can-do”能力与多实现；二者应协作而非互斥。
抽象类能有构造方法，接口不能
Java 里 abstract class 是类，所以可以定义构造方法，哪怕它不能被直接实例化，子类创建时仍会调用它完成初始化逻辑；而 interface 是契约规范，从 Java 8 开始支持 default 和 static 方法，但始终不允许构造方法——写一个就会报错 Illegal constructor declaration。
常见错误：有人试图在接口里加 public MyInterface() {}，编译直接失败。这不是语法糖缺失，是设计意图不同：抽象类参与对象生命周期，接口只管“能做什么”。
- 抽象类的构造方法常用于初始化 shared state（比如日志器、配置对象），子类通过
super()显式调用 - 接口没法持有状态，所有字段默认是
public static final，连private字段都不允许 - 如果需要“带初始化逻辑的契约”，得靠抽象类 + 工厂方法，或组合接口与具体类
一个类只能继承一个抽象类，但能实现多个接口
这是 Java 单继承机制决定的。当你写 class A extends B implements C, D，B 必须是类（可以是抽象类），而 C、D 必须是接口。
典型踩坑场景：想复用两套行为逻辑（比如 Runnable 和 Serializable），但发现两个都是接口——没问题；可如果一个是抽象类（比如自定义的 BaseService），另一个也是抽象类（比如 BaseCache），就只能二选一，或者把其中一个改造成接口。
立即学习“Java免费学习笔记（深入）”；
- 抽象类适合表达“is-a”关系（
MySQLConnectionis aConnection），强调共性实现 - 接口适合表达“can-do”能力（
Comparable、Cloneable），强调角色叠加 - Java 8 后接口支持
default方法，让“多继承行为”成为可能，但不解决状态共享问题
抽象类可以有非抽象方法和 protected 成员，接口不行
抽象类里可以混写 public、protected、private 方法，也可以有非 abstract 的具体实现；而接口中所有方法默认是 public abstract（即使不写），所有字段默认是 public static final，连 protected 都不认。
比如你在抽象类里写一个 protected void log(String msg)，子类可以直接调用；但在接口里写同名方法，编译器会强制改成 public，且子类无法限制访问权限。
- 抽象类适合封装模板逻辑（如
templateMethod()调用几个abstract步骤），子类只需填空 - 接口里的
default方法虽可实现，但无法访问实现类的私有字段，也不能调用this上的非public方法 - 如果需要“受保护的工具方法”，只能放抽象类，接口做不到
Java 8+ 接口能有 default/static 方法，但抽象类更早支持完整实现
default 方法不是为替代抽象类而生的，而是为向后兼容做补丁——比如给 Collection 加 stream()，又不能破坏已有实现类。抽象类从 JDK 1.0 就支持完整方法体，包括构造、字段、静态块、内部类等。
性能上没本质差异，但语义清晰度不同：用 default 方法强行塞逻辑进接口，容易让接口偏离“契约”本意；而抽象类天然就是“半成品类”，混入实现很自然。
- 别为了省一个
extends就把本该是抽象类的逻辑硬塞进接口 - 接口加太多
default方法，等于悄悄变成抽象基类，但丧失了单继承约束带来的设计约束力 - 真正难的是判断：这个“通用逻辑”到底属于领域本质（该放抽象类），还是跨领域能力（该放接口）
最常被忽略的一点：抽象类和接口不是非此即彼的选择，而是协作关系。比如 Spring 的 AbstractBeanFactory 是抽象类，但它实现的 BeanFactory 是接口——前者负责通用流程，后者定义能力边界。选型卡壳时，先问自己：这里有没有必须由子类共享的状态？有没有必须控制访问级别的方法？答案为“是”，抽象类大概率更合适。
