选Pimple、PHP-DI或手写容器需依项目而定：Pimple适合小型项目，轻量易用；PHP-DI支持注解和自动装配，适配中大型项目；手写仅推荐学习或极简场景，易在循环依赖、作用域和参数解析上出错。
PHP中DI容器怎么选：Pimple、PHP-DI还是自己手写？
大多数项目不需要从零造轮子，直接用成熟容器更稳。Pimple轻量但功能有限，PHP-DI支持注解和自动装配，适合中大型项目；手写容器只推荐用于学习或极简场景——它容易在循环依赖、作用域（如singleton vs prototype）和参数解析上翻车。
常见错误现象：PHP Fatal error: Uncaught ReflectionException: Class xxx does not exist，通常是因为类名拼写错误、未启用自动加载，或配置里写了不存在的类路径。
- 确认
composer.json中已声明"autoload": {"psr-4": {...}}并执行过composer dump-autoload - 避免在容器定义里硬编码绝对路径，统一用类名字符串，交由自动加载器处理
- 若用
PHP-DI，禁用enableAnnotationBasedInjection可显著提升性能，尤其在无注解的项目中
建造者模式怎么和DI容器配合？别在build()里new对象
建造者的核心价值是封装复杂对象构造逻辑，不是替代DI。把new塞进build()方法里，等于绕过容器管理，导致依赖无法被替换、无法被测试桩（mock）。
正确做法是让建造者本身由容器创建，并通过构造函数接收已解析好的依赖：
立即学习“PHP免费学习笔记（深入）”；
// 容器配置示例（PHP-DI）
return [
UserService::class => function (ContainerInterface $c) {
return new UserService(
$c->get( UserRepository::class ),
$c->get( EmailService::class )
);
},
UserBuilder::class => \DI\create()->constructor(
\DI\get(UserRepository::class),
\DI\get(EmailService::class)
)
];
-
UserBuilder不负责实例化UserRepository，只接收并组合它们 - 如果
UserBuilder需要动态参数（如$userId），不要把它注册为单例，改用工厂闭包 - 避免在
build()中调用$container->get()——这会让依赖关系隐式化，破坏可读性
配置驱动的对象装配：YAML/PHP数组哪个更靠谱？
用PHP数组配置最直接，无额外解析开销，IDE支持好，且能复用变量和条件逻辑；YAML看着清爽，但实际开发中容易因缩进错误或类型隐式转换引发诡异问题，比如true被解析成字符串"true"。
典型坑点：PHP-DI的DI\Config默认不递归合并嵌套数组，多文件配置时需显式调用withDefinitions()。
- 配置项键名必须与目标类构造函数参数名严格一致（或通过
@Inject注解指定） - 若依赖是接口，配置中必须绑定具体实现类，例如
UserRepositoryInterface::class => UserRepository::class - 慎用
DI\factory()包裹闭包——每次获取都执行，可能触发重复初始化，应优先用DI\create()+ 构造注入
为什么“动态”装配常卡在运行时才报错？
因为PHP是动态语言，容器直到get()被调用才会真正解析依赖链。你写完所有配置，php -l也检查不出Class Not Found或参数类型不匹配。
解决思路不是等上线才发现，而是加一层轻量验证：
- 在CLI命令或部署脚本中调用
$container->get(SomeService::class)做探针（注意避开有副作用的构造逻辑） - 对关键服务编写最小单元测试，仅验证容器能否成功构建实例
- 若用
PHP-DI，开启ProxyManager后可提前发现接口实现缺失，但会增加启动开销
最易被忽略的是配置中的环境差异：开发环境能跑通的get('cache.adapter.redis')，到了没装Redis扩展的测试机就直接Fatal error——这类问题不会出现在静态分析里，得靠配置分组和环境感知加载来兜底。
