接口定义契约，不绑定具体实现，只声明方法签名以规范行为；抽象类封装可复用逻辑，解决“部分怎么做”，二者在桥接模式中分工明确：接口管实现层契约，抽象类管抽象层扩展点。
接口定义契约，不绑定具体实现
接口只声明方法签名，不提供任何实现逻辑，强制所有实现类遵守同一行为规范。它解决的是“能做什么”，而不是“怎么做”。比如 MessengerInterface 只规定 send() 方法必须存在，但不关心是发邮件、短信还是 Slack 消息。
- 接口不能有属性、构造函数或具体方法，只有
public方法声明 - 一个类可
implements多个接口，实现多重能力组合（如LoggerInterface+NotifierInterface） - 接口变更代价高：一旦新增方法，所有实现类都得补上，所以应尽量小而稳定
- 别用接口模拟“配置项”或“数据容器”，那是
DTO或array的事，不是接口的职责
抽象类提供可复用的公共逻辑
抽象类适合封装多个子类共有的代码，比如初始化、通用校验、模板方法骨架。它解决的是“部分怎么做”，同时保留“哪些必须由子类决定”的灵活性。
- 抽象类可以含
protected属性、具体方法、抽象方法，甚至构造函数 - 子类只能
extends一个抽象类，但可同时实现多个接口 - 常见误用：把本该是组合关系的功能塞进抽象基类（例如让
Checkout继承BaseMailer），这会污染继承链 - 抽象方法必须被子类
public实现，且参数类型、返回类型需严格一致（PHP 8+ 支持协变返回与逆变参数）
依赖注入时优先面向接口，而非抽象类
当你在构造函数里声明依赖，类型提示应该用接口，而不是抽象类——因为接口更轻、更专注契约，也更容易被 Mock 替换用于测试。
- 错误写法：
public function __construct(MailerAbstract $mailer)—— 把实现细节暴露给了调用方 - 正确写法：
public function __construct(MessengerInterface $messenger)—— 调用方只知行为，不知实现 - 抽象类适合做“中间层”，比如多个邮件服务共享连接池、重试逻辑，此时可让
SmtpMailer和SendgridMailer都继承AbstractMailer，但对外仍通过MessengerInterface注入 - 若某抽象类没有抽象方法，又没提供真正复用的逻辑，那它大概率该被删掉，直接用接口更干净
桥接模式下，接口和抽象类分工明确
桥接模式本质是把“谁做事”（抽象层）和“怎么做事”（实现层）拆开。这时接口管实现层契约，抽象类管抽象层扩展点，两者各司其职。
- 实现层用接口（如
Formatter），保证不同格式器（HtmlFormatter、JsonFormatter）可自由替换 - 抽象层用抽象类（如
Service），封装通用流程（如日志记录、缓存判断），再委托给Formatter执行核心格式化 - 别把
Formatter声明为抽象类——它不需要共享状态或默认行为，接口就够了 - 如果抽象类
Service自身也要被多态使用（比如传给统一调度器），那它最好也实现一个顶层接口（如Runnable），方便类型约束
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
