依赖注入是将“要用的类”提前准备并注入，而非类内 new 创建，解决类间紧耦合问题；构造函数注入适用于强制依赖，setter 注入适用于可选功能；容器可自动解析依赖但需类型提示、接口绑定及避免循环依赖。
依赖注入（DI）在 PHP 架构里，不是什么黑科技，就是把“要用的类”提前准备好，再塞进另一个类里，而不是让那个类自己 new 出来。
它解决的核心问题很实在：你改一个类，别牵连七八个地方一起动。
为什么不用 new 而要搞依赖注入？
因为直接 new 会把类和具体实现死绑在一起。比如：
class OrderService {
public function process() {
$payment = new AlipayGateway(); // 硬编码！
return $payment->pay();
}
}一旦要切到 WechatPayGateway，就得改这行代码——所有用到 OrderService 的地方都得跟着测、跟着发版。
立即学习“P
HP免费学习笔记（深入）”；
换成依赖注入后：
class OrderService {
public function __construct(private PaymentGateway $gateway) {}
public function process() {
return $this->gateway->pay();
}}
谁创建 $gateway？容器决定。你只管用接口、写逻辑。
- 测试时可以轻松传入
MockPaymentGateway - 上线前换支付渠道，只需改容器绑定，不碰业务类
- 类之间不再“知道对方怎么造出来”，只约定“能做什么”
__construct 注入 vs setXxx 注入，什么时候选哪个？
构造函数注入是默认首选，适用于必须存在、不可为空的依赖；setter 注入适合可选功能，比如日志、缓存开关。
-
__construct注入：强制依赖、不可变、利于类型安全和 IDE 提示 -
setLogger注入：允许运行时动态替换，但容易漏设、状态不稳 - 别混用：一个类里既有构造注入又有 setter 注入，会让初始化逻辑分散、难追踪
反例（危险）：
class UserService {
private MailerInterface $mailer;
private ?CacheInterface $cache = null;
public function __construct(MailerInterface $mailer) {
$this->mailer = $mailer;
}
public function setCache(CacheInterface $cache) {
$this->cache = $cache; // 忘调用就崩
}}
容器自动解析依赖，真能“全自动”？常见翻车点
现代 PHP 容器（如 Laravel 的 Container、Symfony 的 ServiceContainer）确实能靠反射自动构建依赖树，但有几个隐形门槛：
- 类必须有完整类型提示（
private Logger $logger），否则容器猜不出该给什么 - 接口没绑定实现时，容器报错：
Target [LoggerInterface] is not instantiable - 循环依赖（A 依赖 B，B 又依赖 A）会导致解析失败，错误信息往往不直观
- 闭包绑定写错参数顺序，或忘了
use ($container)，运行时报Undefined variable
建议做法：
- 接口必须绑定具体类：
$container->bind(LoggerInterface::class, FileLogger::class) - 复杂对象用闭包定义：
$container->bind(Database::class, fn() => new Database($config)) - 启动时加
$container->build(OrderService::class)预检依赖是否可解析
依赖注入本身很简单，难的是坚持用接口契约、管住手别写 new、以及在容器配置里守住边界。很多项目 DI 半途而废，不是容器不行，是人没把“谁负责创建”这件事真正交出去。
