接口管“能做什么”，抽象类管“怎么去做一半”；接口定义行为契约，抽象类提供部分实现并留定制空间；多实现选接口，共用逻辑多选抽象类。
接口与抽象类不是用来背概念的，而是解决具体问题的工具。用对了，代码结构清晰、扩展容易；用错了，反而增加理解成本和维护负担。
明确分工：接口管“能做什么”，抽象类管“怎么去做一半”
接口定义行为契约，不关心实现细节；抽象类提供部分通用实现，同时保留子类定制空间。
- 当多个类需要统一调用方式但实现完全不同（比如支付方式：微信支付、支付宝、银联），优先用接口——
interface Payment声明pay()和refund()，各实现类自由发挥 - 当多个类有大量共用逻辑，但关键步骤必须由子类决定（比如不同报表导出：Excel、PDF、CSV），适合抽象类——
abstract class ReportExporter封装文件命名、数据预处理、日志记录，只把doExport()留为抽象方法 - 一个类可以实现多个接口，但只能继承一个抽象类。如果业务需要组合能力（如“可导出”+“可打印”+“可缓存”），接口更灵活
实战中常被忽略的关键细节
很多问题不是不会用，而是没注意约束条件和协作方式。
- 接口中的方法默认是 public abstract，不能加访问修饰符；字段默认是 public static final，别试图在接口里写可变状态
-
抽象类的构造函数可以有参数，用于初始化共享资源（如数据库连接池、配置对象），子类通过
super(...)传递 - Java 8+ 接口可含 default 方法，适合给已有接口“安全升级”——比如新增
retry()逻辑，老实现类不用改就能用；但别滥用，default 方法应是真正通用的辅助逻辑，不是主干流程 - 抽象类中可以有普通方法、静态方法、甚至 main 方法，方便单元测试或独立运行验证基础流程
组合使用：用接口定义能力，用抽象类组织实现
真实项目里，二者经常配合出现，形成稳定又灵活的骨架。
- 先定义接口：
interface DataProcessor，声明process(List<record>)</record>和validate(Record) - 再写抽象基类：
abstract class BaseDataProcessor implements DataProcessor，内置通用校验规则、异常包装、耗时统计等，只让子类专注doProcess() - 最后具体实现：
class OrderProcessor extends BaseDataProcessor，只需补全订单特有的转换逻辑，其余都复用 - 这样既保证所有处理器对外行为一致（接口约束），又避免重复造轮子（抽象类封装）
低代码场景下的智能选择策略
在代码生成器或平台化开发中，接口与抽象类的选择可自动化。
- 若业务模块强调协议兼容性（如对接第三方系统、开放API），生成接口骨架，确保契约稳定
- 若模块强调流程一致性（如审批流、风控引擎），生成抽象类骨架，强制继承统一前置/后置处理
- 规则引擎可基于注解判断：标注
@ApiContract→ 生成接口；标注@WorkflowCore→ 生成抽象类 - 生成后保留扩展点，比如抽象类里留
protected void beforeProcess() {}空钩子，子类按需重写
