接口定义“能做什么”的行为契约，只声明public方法且支持多实现；抽象类定义“是什么”与“怎么做”的中间层，可含抽象/具体方法及属性，仅支持单继承。
PHP 中的接口（interface）和抽象类（abstract class）都是实现代码抽象与规范的重要机制，但它们定位不同、使用场景有别。理解二者的核心差异与适用边界，是写出可维护、可扩展面向对象 PHP 代码的关键。
接口：定义“能做什么”的契约
接口只声明方法签名，不提供具体实现，也不允许属性（PHP 8.1+ 支持 readonly 属性，但非常规用法）。它强调的是行为约定，而非结构继承。
- 所有方法默认为 public 且必须被实现（子类不可降低可见性）
- 一个类可通过 implements 实现多个接口，支持“多实现”
- 适合解耦协作场景，比如
LoggerInterface、CacheInterface，让不同日志驱动（FileLogger、RedisLogger）统一遵循同一套方法名和参数规则 - PHP 8.0+ 支持接口中定义常量、静态方法（仍需在实现类中提供具体逻辑）
抽象类：定义“是什么”与“怎么做”的中间层
抽象类不能被实例化，用于被继承；它既可包含抽象方法（无实现，子类必须重写），也可包含具体方法（含逻辑，子类可直接用或覆写）。
- 支持 protected/private 方法、属性、构造函数、静态成员，封装能力更强
- 一个类只能 extends 一个抽象类（单继承限制）
- 适合有共性逻辑又需强制子类定制的场景，比如
PaymentProcessor抽象类统一处理订单验证、日志记录，但把doPay()留给WechatPay、Alipay各自实现 - 抽象类可实现接口，把契约落实为半成品骨架
接口 vs 抽象类：选哪个？看三个关键点
不必纠结“哪个更好”，而要看设计意图：
立即学习“PHP免费学习笔记（深入）”；
- 是否需要共享代码逻辑？ → 需要 → 优先考虑抽象类；纯行为约束 → 接口更轻量
-
是否要求类具备多重身份？ → 比如一个服务既要可缓存（
Cacheable），又要可序列化（Serializable）→ 接口支持多实现，抽象类不行 -
是否在构建领域模型的层级结构？ → 如
Animal（抽象类）→Dog/Cat，体现 is-a 关系 → 抽象类更自然
实战建议：组合使用效果更佳
大型项目中，常见“接口 + 抽象类 + 具体实现”三层结构：
- 先定义
UserServiceInterface明确对外契约（find()、create()） - 再提供
AbstractUserService封装通用校验、事件触发等重复逻辑 - 最后由
DatabaseUserService或ApiUserService继承抽象类并实现接口，专注数据源差异
这样既保证扩展性（换数据源只需新实现类），又避免重复编码（公共逻辑集中维护）。
基本上就这些。接口管“协议”，抽象类管“骨架”，用对地方，代码才真正松耦合、易测试、好演进。
