优先用interface定义行为契约且无需状态或构造逻辑；需共享字段、构造器或强制初始化流程时用abstract class；判断依据：是否需状态、构造控制、跨无关类复用。
什么时候该用 interface 而不是 abstract class
当需要定义一组行为契约，且不关心实现细节、也不需要共享状态或构造逻辑时，优先选 interface。Java 8+ 允许 interface 有 default 和 static 方法，但它们不能有实例字段、不能有构造器、不能有 protected 或 private 非静态方法。
- 多个不相关的类想实现同一套能力（比如
Runnable、Comparable），只能靠interface—— Java 不支持多继承abstract class - 需要被
record、enum或已存在类实现时，只能用interface - 若未来可能由不同模块分别实现，且希望解耦编译依赖，
interface的二进制兼容性更好（新增default方法通常不破坏实现类）
abstract class 真正不可替代的场景
当你需要提供可复用的骨架代码、共享字段、构造器逻辑，或者强制子类走特定初始化流程时，abstract class 是唯一选择。
- 子类必须共用某些实例变量（如
protected String name;），interface无法声明非public static final字段 - 需要在构造过程中执行校验或资源预分配（比如抽象日志组件要求传入
Logger实例） - 已有类层级中，父类已承担部分实现，又需约束下层行为（例如
AbstractList提供了大部分List方法，只留get(int)和size()抽象）
Java 8+ 后常见的误用陷阱
开发者常因 default 方法的存在，误以为 interface 可以替代 abstract class，但语义和限制完全不同。
-
default方法不能访问实现类的私有字段，也不能调用this上的非接口方法，本质上仍是“契约侧”的扩展，不是“继承侧”的复用 - 如果两个
interface提供了同签名的default方法，实现类必须显式重写该方法，否则编译失败 —— 这不是多继承的便利，而是冲突显式化 -
abstract class的子类只能单继承，但可以同时实现多个interface；反过来，interface不能extends类，只能extends其他interface
一个务实的判断流程
写新类型前，快速问自己三个问题：
网趣网上购物系统旗舰版
下载
网趣网上购物系统支持PC电脑版+手机版+APP，数据一站式更新，支持微信支付与支付宝支付接口，是专业的网上商城系统，网趣商城系统支持淘宝数据包导入，实现与淘宝同步更新!支持上传图片水印设置、图片批量上传功能，同时支持订单二次编辑以及多级分类隐藏等实用功能，新版增加商品大图浏览与列表显示功能，使分类浏览更方便，支持最新的支付宝即时到帐接口。
立即学习“Java免费学习笔记（深入）”；
- 是否需要保存状态（字段）？→ 是 → 用
abstract class - 是否需要控制构造过程（比如参数校验、资源初始化）？→ 是 → 用
abstract class - 是否预期被完全不相关的类实现（比如 UI 组件和网络请求类都要“可取消”）？→ 是 → 用
interface
如果三个都是“否”，再看是否只是定义常量和纯行为——那 interface 更轻量；如果后续发现要加字段或构造逻辑，就说明当初该选 abstract class。
// 示例：错误地试图在 interface 中存状态
interface BadCounter {
private int count = 0; // 编译错误！interface 中不能有非 static final 字段
default void inc() { count++; } // 也无法访问这个 count
}
// 正确做法：用 abstract class 封装可变状态
abstract class Counter {
protected int count = 0;
public void inc() { count++; }
public abstract void reset();
}
真正难的不是语法，是第一次设计时对“谁该负责什么”的判断——一旦把状态或构造逻辑塞进 interface，后面要么改接口（破坏兼容性），要么绕弯子（比如用 ThreadLocal 模拟状态），代价远高于初期多花两分钟想清楚。
