别再手动 new 了：PHP 依赖注入的避坑指南

写 PHP 项目久了，总会碰到这种场面：一个订单处理类里写死了微信支付 SDK，运营突然要求上线抖音支付。改底层？牵一发而动全身；写自动化测试？到处是强依赖导致的 Mock 报错。这类重构噩梦的本质，是模块之间绑得太死。把对象的创建权交出去，让外部把需要的工具递进来，就是依赖注入（Dependency Injection）真正想干的事。

它常被误读成高深架构，实际逻辑非常直白。就像餐厅后厨，厨师不需要自己进市场挑菜，菜单写好标准，采购按标备料直接送进灶台。代码里，它解决的是“对象该从哪里来”。传统写法在类内部直接 new 依赖项，注入后改为将依赖通过参数传入当前类。控制权转移，硬编码断裂，后续替换或隔离测试就顺理成章。

落地不用一上来就搭重型框架。从构造函数入参改起最踏实。

第一步：抽离契约层。业务逻辑只认接口不认具体类。定义 PaymentStrategyInterface::handle(array $data)，所有支付方式统一遵循这个签名。

第二步：改造核心类签名。删除原有的 $this->wxPay = new WxPayClient();，替换为 public function __construct(PaymentStrategyInterface $strategy)。类不再关心对方长什么样，只确认它能干活。

第三步：在调度层拼装配方。路由入口或应用启动文件中明确绑定：$handler = new OrderProcessor(new AliPayClient());。此时切底层方案，只需变动这一行实例化代码，上层业务零改动。

新手常踩的坑是“为解耦而解耦”。几十行的辅助函数硬塞 DI 容器，反而堆出满屏模板代码。依赖注入该出手的场景很明确：可插拔的第三方组件、携带运行状态的服务层、以及必须产出稳定断言的单元测试块。碰到 A 类依赖 B、B 又回头依赖 A 的循环引用，注入机制会直接抛出实例化死锁。这往往说明领域边界画重了，该拆成纯数据对象就别强行塞进服务管道。

代码量撑过中型项目后，手工拼装会变得臃肿。引入轻量容器能砍掉大量胶水逻辑。容器的价值不在神秘感，而在延迟解析与生命周期管控。注册好键值映射后，请求 make(OrderProcessor::class) 会自动沿着依赖树递归补齐下级实例。注意把容器范围控制在当前请求周期，静态单例拿出来的缓存对象极易引发并发脏数据，必要时配合工厂闭包重置状态。

依赖注入不是万能贴，它是处理复杂度的精准手术刀。用对了，代码变薄、边界清晰、迭代不伤筋动骨；用错了，只会多缠一层抽象绷带。摸清传递时机，守住必要原则，你的 PHP 工程才能真正跑起来，而不是停在架构图里。