接口不能有构造方法，抽象类可以；接口无实例字段，变量默认public static final；一个类只能继承一个抽象类但可实现多个接口；接口定义能力契约，抽象类定义类型骨架。
接口不能有构造方法，抽象类可以
这是最直接的语法差异。Java 规定 interface 里不允许定义任何构造方法，哪怕显式写 public MyInterface() {} 都会编译报错 Illegal constructor declaration。而抽象类本质仍是类，支持构造方法（哪怕不能直接 new），常用来初始化 shared state 或强制子类传参。
典型场景：需要为所有实现类提供统一的配置对象或日志器实例时，抽象类的构造方法比在每个实现类里重复写初始化逻辑更安全、更可控。
注意点：
- 抽象类的构造方法只能被子类调用（通过
super()），不会被接口实现者“继承” - 接口中若误写构造方法，IDE 通常只提示语法错误，但部分老版本 javac 可能报错不明确，容易卡在“为什么这个方法不生效”上
接口默认方法和静态方法从 Java 8 开始存在，但不能有实例字段
Java 8 引入 default 和 static 方法让接口具备一定行为扩展能力，但它们仍有严格边界：接口里声明的变量自动是 public static final，不能有普通实例字段（即没有 private String name; 这种）。
立即学习“Java免费学习笔记（深入）”；
而抽象类可自由定义 private、protected、static、实例字段，也能控制 getter/setter 的可见性。
常见误判：
- 把
default方法当成“可以替代抽象类”的理由——它无法访问实现类的私有状态，也不能做构造期初始化 - 在接口里写
public int count = 0;，以为能被实现类修改——实际是常量，改了就编译失败 - 试图在
default方法里调用this.toString()并期望它走实现类逻辑——可以，但若实现类没重写，就会回退到Object.toString()，容易引发空指针或语义错乱
一个类只能继承一个抽象类，但能实现多个接口
这是 Java 单继承机制决定的底层约束。抽象类用于表达“是什么（is-a）”关系，比如 Animal 抽象类下有 Dog 和 Cat；接口用于表达“能做什么（can-do）”契约，比如 Runnable、Serializable、Comparable 可同时加在一个类上。
设计取舍的关键信号：
- 如果多个类型共享**核心数据结构和部分通用逻辑**（如都有
id、createdAt、validate()基础校验），优先用抽象类封装 - 如果只是需要统一调用入口（如所有消息都支持
serialize()、retry()），且各实现完全独立，用接口更松耦合 - 混合使用很常见：抽象类实现某接口，再由具体子类继承该抽象类——既复用逻辑，又满足多实现需求
接口更适合定义能力契约，抽象类更适合定义类型骨架
这不是语法限制，而是长期实践中沉淀的设计直觉。比如 Collection 是接口，因为 ArrayList、LinkedList、HashSet 完全不同，只保证“能 add/remove/size”；而 AbstractList 是抽象类，因为它封装了 indexOf()、lastIndexOf() 等基于迭代器的通用实现，子类只需提供 get(int) 和 size() 就能开箱即用。
容易被忽略的细节：
- 接口一旦发布（尤其被第三方实现），新增抽象方法等于破坏性变更；而抽象类新增
protected方法或default方法影响较小 - 抽象类的字段和方法可设为
package-private，方便模块内协作；接口一切对外公开，无法隐藏内部约定 - 泛型擦除后，抽象类的类型参数可能保留运行时信息（如继承
AbstractProcessor<string></string>），接口做不到这点
真正难的不是语法区分，而是判断“这个共性到底属于身份还是能力”。多数重构卡点，其实卡在最初那句“它究竟是个什么，还是它能干啥”。
