依赖倒置原则（dip）在 php 中要求高层模块依赖抽象接口而非具体实现，所有实现类必须实现稳定接口，且依赖须通过构造函数注入，配合 ioc 容器实现可维护切换。
依赖倒置原则（DIP）在 PHP 架构里不是“加个接口就完事”的形式主义，而是决定你改一行数据库代码会不会让订单、支付、通知全挂掉的关键防线。
它真正起作用的场景，是你明天要从 MySQL 切到 Redis 存用户会话，或者把短信服务从阿里云换成腾讯云——而控制器、服务类、业务逻辑层一个字都不用动。
PHP 里不写接口，光靠类型提示也能“假装”依赖倒置？
不能。PHP 是弱类型语言，function send(SmsService $service) 看似有约束，但如果你传个没继承 SmsService 的新类进去，PHP 7.4+ 会直接报错；可如果写成 function send($service)，哪怕你传的是个数组或字符串，只要它有 send() 方法，运行时也不报错——这叫“鸭子类型”，不是依赖倒置。
真正落地 DIP 必须满足两点：
立即学习“PHP免费学习笔记（深入）”；
- 高层模块（如
OrderService）只依赖interface PaymentGateway，不依赖AlipayClient或WechatPayClient - 所有具体实现（
AlipayClient等）必须implements PaymentGateway，且接口定义稳定（比如只含pay()、query()，不含refundV2()这种带版本号的方法）
interface PaymentGateway
{
public function pay(float $amount, string $orderNo): bool;
public function query(string $orderNo): array;
}
<p>class AlipayClient implements PaymentGateway
{
public function pay(float $amount, string $orderNo): bool { /<em> ... </em>/ }
public function query(string $orderNo): array { /<em> ... </em>/ }
}</p><p>// Controller 中只认 interface，不 care 具体是谁
class OrderController
{
public function __construct(private PaymentGateway $gateway) {}</p><pre class='brush:php;toolbar:false;'>public function checkout(): void
{
$this->gateway->pay(99.9, 'ORD-20251230');
}}
为什么 new 出来的对象一多，DIP 就立刻失效？
常见错误：在构造函数里写 new MySQLConnection()、在方法里写 new Logger()、甚至 new ConfigLoader() —— 这些都是硬编码依赖，等于把低层细节钉死在高层逻辑上。
后果很直接：
- 单元测试无法 mock 数据库连接，只能连真实 DB，CI 流水线变慢甚至失败
- 想换日志驱动（从 file → Sentry），得全局搜
new FileLogger改十几处 - IOC 容器（如 Laravel 的
Container或 Symfony 的ServiceContainer）根本接管不了这些new出来的实例，依赖注入链断裂
正确姿势：所有外部依赖都通过构造函数或 setter 注入，且类型必须是 interface 或 abstract class。
PHP 的 IOC 容器怎么配合 DIP 落地？
容器本身不等于 DIP，但它让 DIP 可维护。没有容器，你得手动 new 一堆依赖再层层传参；有容器后，你只需声明“我要一个 PaymentGateway”，它自动给你配好 AlipayClient 或 WechatPayClient —— 切换只需改一行绑定配置。
一个极简容器绑定示例（参考 Laravel 的 service container 思路）：
$container = new Container(); $container->bind(PaymentGateway::class, AlipayClient::class); // 换渠道？只改这一行： // $container->bind(PaymentGateway::class, WechatPayClient::class); <p>$orderService = $container->get(OrderService::class); // 自动注入 AlipayClient
注意坑点：
- 别在
bind()里传匿名函数做复杂初始化，容易掩盖依赖关系 - 避免循环依赖：A 依赖 B，B 又依赖 A —— 容器报错前，先检查接口设计是否合理
- 接口方法别贪多，一个
PaymentGateway接口里塞 12 个方法，最后只有 2 个被实现，说明抽象过度
DIP 在 PHP 里最易被忽略的一点：它不是为“未来扩展”而存在的，是为“今天改 bug 不敢动”而存在的。当你发现改一个缓存类，得同步改七八个 service 的构造函数参数，那就是 DIP 已经崩了——不是框架不行，是抽象层早被绕过去了。
