抽象类约束子类必须走同一条路，强调is-a关系与结构统一；接口约束实现类必须答得上这一题，强调can-do契约与能力组合，前者管“怎么做”，后者管“做什么”。
抽象类和接口在规范约束上的核心区别，不在于“能不能写方法体”，而在于“谁来承担约束责任”以及“约束的粒度和意图不同”。
抽象类：约束子类必须走同一条路
抽象类的约束是结构性、继承链绑定的。它要求子类必须属于同一语义家族（is-a），并强制继承其字段、构造逻辑、模板流程和部分实现。比如定义一个 PaymentProcessor 抽象类，它可能自带 orderNo 字段、initLog() 初始化日志方法、validate() 公共校验逻辑，还留一个 doPay() 抽象方法让子类补全。这种设计天然意味着：
- 所有子类共享状态（如订单号、渠道配置）
- 子类初始化时必须调用父类构造器
- 新增一个非默认的抽象方法，所有子类立刻编译报错，必须响应
- 修改已有具体方法，所有子类行为同步改变——强耦合，高管控
接口：约束实现类必须答得上这一题
接口的约束是契约性、能力导向的。它只声明“你对外要能做什么”，不干涉你是谁、怎么存数据、内部怎么组织。例如 Refundable 接口只规定 refund(double amount) 和 canRefund() 两个行为，支付渠道、物流单、会员权益等完全无关的类都可以实现它。关键特点是：
- 不带状态，无法定义普通实例变量，杜绝隐式共享
- 新增抽象方法会破坏所有实现类，但新增
default方法不会——接口更擅长渐进式演进 - 一个类可以同时实现
Refundable、Cancelable、Trackable，能力自由叠加，无继承冲突 - 接口之间还能
extends多个其他接口，形成能力组合树
约束强度与演化成本的对比
抽象类的约束像一份劳动合同：签了就得按岗位职责+公司制度执行，改条款需全员重签；接口的约束更像一份服务协议：只要响应约定的 API，底层用什么技术、怎么部署，对方不管。所以：
- 当你需要统一初始化、共用字段、固化执行流程（比如模板方法模式），选抽象类——它提供的是“可运行的骨架”
- 当你需要定义跨领域行为、支持多角色能力、预留未来扩展弹性，选接口——它提供的是“可协商的契约”
- Java 8+ 的
default方法不是让接口“变成抽象类”，而是让契约在不破坏旧实现的前提下，增加共识性默认行为（比如所有Logger接口都应支持logErrorWithTrace()的默认实现）
本质上，抽象类管“怎么做”，接口管“做什么”。前者靠继承强制落地，后者靠实现自愿履约。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
