Webman默认不启用自动依赖注入，需手动接入PHP-DI并规避闭包路由绕过容器、Typed property未初始化访问、接口未显式绑定等关键陷阱。
Webman 默认不启用自动依赖注入，想用 PHP-DI 的完整能力（比如属性注入、构造函数自动装配、接口绑定），必须手动接入并绕过几个关键陷阱——否则大概率遇到 Typed property must not be accessed before initialization 或 Entry "X" cannot be resolved 这类报错。
闭包路由里依赖注入完全失效
这是 Webman 项目中最常踩的坑：你在 route.php 里写 Route::get('/test', fn() => (new IndexController())->index())，控制器里的 private UserService $service 就永远得不到注入。
- 闭包路由不经过框架容器实例化流程，
new IndexController()是纯手动创建，PHP-DI 压根没机会运行 -
#[Inject]注解只对容器创建的对象生效，闭包里任何new或直接调用都等于“绕过注射站” - 解决办法只有两个：
Route::controller()声明控制器类（让框架接管），或改用构造函数注入 +Container::get(IndexController::class)显式获取
Typed property 报错不是配置问题，是时机问题
PHP 8+ 的类型化属性（如 private UserService $service）在未初始化时不可读取，而 PHP-DI 的属性注入是「对象创建后反射赋值」，中间存在时间差。
- 如果控制器方法里在注入完成前就访问了该属性（比如构造函数末尾就调
$this->service->do()），立刻爆错 - 低版本 PHP-DI（php-di/php-di:^7.0
- 临时调试可改成
private ?UserService $service = null，但生产环境应优先用构造函数注入——它在new阶段就完成依赖装配，无时机竞争
接口绑定没做，autowiring 就会卡住
PHP-DI 的自动装配（useAutowiring(true)）不是万能的，它只解决“怎么实例化”，不解决“该用哪个实现”。
立即学习“PHP免费学习笔记（深入）”；
- 比如你写了
public function __construct(private CacheInterface $cache)，但容器里没注册CacheInterface::class => RedisCache::class，就会抛Entry "CacheInterface" cannot be resolved - 不要只靠
addDefinitions()扫描类，接口必须显式绑定，否则 autowiring 不知道该选 Redis 还是 Memcached - 多个实现共存时（如
LoggerInterface对应 FileLogger 和 SlackLogger），得用@Named注解或set()->to()明确指定，否则容器无法抉择
自己 new 实例时，PHP-DI 完全不工作
很多人以为配好 config/container.php 后，所有 new XxxService() 都会自动注入——其实只对框架主动创建的控制器、中间件、监听器有效。
- 业务代码里写
new UserService()，等于亲手把对象从容器里拽出来，PHP-DI 对它视而不见 - 正确做法是统一走容器：无参用
Container::get(UserService::class)，有参用Container::make(LogService::class, [$path, $name]) - 第三方 SDK 回调里必须
new的对象，别让它持依赖，把依赖拆成方法参数传入（如$sdk->onEvent(fn($data) => $this->handle($data, $userService))）
真正难的不是配通 PHP-DI，而是让整个代码路径都尊重容器生命周期——一旦某个环节手动 new 或闭包绕行，注入链就断了，而且错误往往延迟到属性被读取那一刻才暴露。
