抽象类和接口本质不同：抽象类聚焦“是什么”（is-a关系、共享状态与模板复用），接口聚焦“能做什么”（can-do关系、能力契约与解耦）。语法上抽象类支持构造器、字段、多态方法，可单继承；接口仅声明行为，字段默认public static final，方法默认public abstract，支持多实现与多继承。
抽象类和接口不是“差不多”的替代品，它们解决的是不同层面的问题：抽象类聚焦于“是什么”，接口聚焦于“能做什么”。选错会导致继承体系僵化、扩展困难或职责混乱。
语法结构差异
这是最直观的区分点，直接影响代码怎么写：
- 抽象类可以有构造方法、普通字段（private/protected/public）、静态块、静态方法、具体实现方法，也能包含抽象方法
- 接口不能有构造方法；所有字段自动是 public static final 常量；所有方法默认是 public abstract（Java 8+ 允许 default 和 static 方法，但不改变其契约本质）
- 一个类只能 extends 一个抽象类，但可以 implements 多个接口；接口之间支持多继承（extends 多个接口）
- 抽象类的成员可设为 private 或 protected，用于封装内部逻辑；接口所有成员天然公开，强调契约可见性
设计意图与建模逻辑
语法是表象，设计才是关键。用错场景，再规范的代码也难维护：
- 抽象类表达 is-a 关系：比如
Animal是基类，Dog和Cat是它的子类——它们本质上都属于“动物”这个范畴，共享名字、年龄、呼吸等属性和通用行为 - 接口表达 can-do 或 has-a-feature 关系：比如
Flyable、Swimmable、Serializable——这些不是类型归属，而是能力标签，Duck可以同时飞又能游，Airplane能飞但不属于动物体系 - 抽象类适合做模板式复用：新增一个通用方法（如
logCreationTime()），子类自动继承；接口一旦加新抽象方法，所有实现类必须响应修改，属于强契约约束
实际使用决策指南
不靠死记硬背，而看问题本质：
- 需要共享状态（如共用字段、初始化逻辑）？→ 优先考虑抽象类（它有构造器，能完成对象构建阶段的设置）
- 多个不相关的类要统一支持某项能力（如日志、序列化、权限校验）？→ 用接口，避免强行拉进同一继承链
- 未来可能频繁扩展行为，且希望不影响现有实现？→ 抽象类更友好（加 default 方法在抽象类里）；若必须用接口，Java 8+ 的 default 方法可缓解，但不宜滥用，否则模糊职责边界
- 框架设计中需解耦调用方与实现方（如 Spring 的
BeanFactory、ApplicationContext）？→ 接口是首选，便于 mock、代理、SPI 扩展
版本演进中的注意事项
Java 8 引入 default/static 方法后，接口能力增强，但没改变根本定位：
- default 方法是为向后兼容服务的（如给
Collection加stream()），不是用来替代抽象类的“模板逻辑” - 接口里仍不能定义实例字段、不能有构造器、不能有 protected 方法——这些限制守住“纯契约”的底线
- Java 9 支持 private 接口方法，仅用于辅助 default 方法，进一步说明：接口仍是围绕“行为声明”优化，而非转向“状态+行为”混合建模
