关键看语义关系：is-a（是某种事物）选抽象类，has-a/like-a（具备某种能力）选接口；抽象类支持状态共享与构造逻辑，接口支持多实现与行为契约。
选抽象类还是接口，关键不在语法差异，而在你想表达的语义关系。
看关系：是“是不是”还是“能不能”
如果多个类天然属于同一类事物，有明确的继承层级，就用抽象类。比如 猫、狗、鸟都是动物，它们共享名字、生命状态、基础行为（如睡觉），这时 Animal 作为抽象类，体现的是“is-a”关系。
如果不同类只是恰好具备某项能力，彼此无关，就用接口。比如 无人机能飞、超人能飞、飞机也能飞，但它们不是同一种东西；用 Flyable 接口定义“会飞”这个能力，体现的是“has-a”能力契约。
看复用：要不要共享状态和实现逻辑
抽象类允许你封装可复用的状态（如 protected 字段）和具体方法（如通用的日志记录、校验逻辑），子类直接继承就能用。
接口不能存状态，也不能有普通字段——它只管“该做什么”，不管“怎么做”或“用什么数据”。即使 Java 8 后支持 default 方法，也只是补充行为，不承载实例状态。
- 需要共用构造流程、初始化逻辑？→ 抽象类（有构造方法）
- 需要共享字段（如 name、id、lastModified）？→ 抽象类
- 只统一调用入口，底层实现完全独立？→ 接口更干净
看组合：类是否需要多种身份
一个类只能继承一个抽象类，但可以实现多个接口。这决定了它的扩展方式：
- 支付类既要“能退款”，又要“可对账”，还能“支持风控拦截”？→ 分别定义 Refundable、Reconcilable、RiskCheckable 接口，让 Payment 实现全部三个
- 如果硬塞进抽象类，就会被迫拉出一条不自然的继承链，或者把无关职责耦合在一起
接口让类能灵活叠加角色，抽象类则强调单一、清晰的父系归属。
看演进：未来是否要加新行为
给接口加新抽象方法，所有实现类都得改——破坏性大。但加 default 方法，现有实现类可不改动，平滑升级。
抽象类加新具体方法，不影响子类；加新抽象方法，才强制子类响应。
所以：对外暴露的公共契约（尤其被第三方实现时），优先用接口 + default 方法；内部模块间强关联的模板结构，用抽象类更可控。
