PHP-DI需合理配置才能缓解依赖管理，盲目使用set()闭包会导致维护困难；自动注入依赖完整类型提示、接口绑定和唯一实现；应按业务域拆分配置文件；循环依赖实为设计问题，需通过提取接口解耦。
PHP-DI 不是“开箱即用就解决所有依赖问题”的魔法盒。它能显著缓解复杂依赖管理，但前提是配置方式匹配项目真实结构——否则反而增加维护成本。
为什么直接写 set() 闭包会让配置越来越难维护
当你看到类似这样的注册逻辑：
$container->set('user.service', function ($c) {
return new UserService(
$c->get('database'),
$c->get('cache'),
$c->get('mailer'),
new AuthGuard($c->get('jwt.encoder'), $c->get('session')),
$c->get('config')['features']['2fa_enabled']
);
});
问题不在语法错，而在于：每次加一个参数，就得改这个闭包；每个服务都这么写，配置文件迅速变成“胶水代码集合”。更麻烦的是，IDE 无法跳转到 $c->get('xxx') 的定义处，重构时全靠人肉 grep。
- 闭包内硬编码依赖名（如
'database'），拼错不报错，运行时报Entry "database" not found - 参数顺序和类型完全靠开发者记忆，
new UserService($a, $b, $c)和new UserService($b, $a, $c)都能通过 PHP 类型检查 - 环境差异（如测试用 MockDatabase）只能靠条件判断塞进闭包，逻辑混杂
PHP-DI 的自动注入真正起效的前提
自动注入（autowiring）不是默认全开的“银弹”，它依赖三个明确条件同时满足：
- 类必须有完整、无歧义的构造函数类型提示（例如
private DatabaseInterface $db，不能是private $db或private object $db） - 容器里必须已注册对应接口的实现（如
DatabaseInterface::class => \App\Database\PdoDatabase::class）或启用addDefinitions()映射 - 没有同类型多个实现未做明确区分（比如同时注册了
CacheInterface→RedisCache和MemcachedCache，不加@Named就会报错）
常见误操作是只配了类自动发现（->useAnnotations(true)），却没处理接口绑定，结果容器反复抛出 Entry "SomeInterface" cannot be resolved —— 这不是容器坏了，是它诚实告诉你：“我不知道该给这个接口塞哪个具体类”。
立即学习“PHP免费学习笔记（深入）”；
配置膨胀时，别堆 definitions.php，拆成按域分组的数组
把所有服务塞进一个大数组，不如按业务边界切分：
// config/di/api.php
return [
ApiClient::class => \DI\create()
->constructorParameter('baseUrl', '%api.base_url%')
->constructorParameter('timeout', 5),
];
// config/di/infrastructure.php
return [
DatabaseInterface::class => \DI\factory([DatabaseFactory::class, 'create'])
->parameter('dsn', '%database.dsn%'),
CacheInterface::class => \DI\create(RedisCache::class),
];
然后统一加载：
$container = Builder::build();
foreach (glob('config/di/*.php') as $file) {
$container->addDefinitions(require $file);
}
这样做的实际好处：git blame 能快速定位某次缓存策略变更影响了哪些配置；CI 流程中可单独验证 infrastructure.php 是否仍兼容新版本 redis 扩展；测试时只需覆盖 api.php 即可替换全部 HTTP 客户端行为。
循环依赖不是设计缺陷，而是信号：该拆接口了
PHP-DI 报 Circular dependency detected 时，第一反应不该是加 @Inject 或延迟代理，而是检查这两个类是否真的属于同一抽象层级。例如：
-
OrderService依赖NotificationService发货通知 -
NotificationService又依赖OrderService查询订单状态生成消息模板
这说明“查询订单状态”这个能力不该由 OrderService（业务编排层）承担，而应抽成独立的 OrderReader 接口，让两者都依赖它。容器只是暴露了设计耦合，不解决它，换任何 DI 工具都会卡在这里。
