构造函数注入是唯一稳妥的选择，因php 8+类型化属性禁止未初始化访问，而php-di属性注入发生在对象创建后，闭包路由或手动new时无法触发注入导致报错。
Webman控制器必须用构造函数注入，否则在闭包路由或手动 new 时必然报 Typed property must not be accessed before initialization。这不是配置问题，是 PHP 8+ 类型化属性 + php-di 属性注入时机冲突导致的硬性限制。
为什么构造函数注入是唯一稳妥的选择
PHP 8 的 typed property（如 private UserService $service;）不允许未初始化就访问，而 php-di 的属性注入是「对象创建后反射赋值」，存在时间差。闭包路由（Route::get('/', fn() => ...)）不走容器实例化流程，$this->service 一读就崩。
- 构造函数注入在
new阶段完成依赖装配，无初始化空窗期 - 框架对控制器、中间件、监听器等组件默认走容器创建，构造函数注入能被自动识别
- 即使你写了
#[Inject]注解，也只在容器创建的对象上生效，闭包里new IndexController()完全无效
构造函数注入写法与常见错误
正确写法要求类型提示明确、参数顺序与容器注册一致，并避免在构造函数中提前使用注入属性：
- 必须用
public function __construct(UserService $service, Logger $logger)形式，不能省略类型提示 - 不要在
__construct()末尾调用$this->service->doSomething()—— 此时 php-di 尚未完成注入（尤其多层依赖时） - 若依赖类本身也需要注入，确保它也被容器管理（即没被
new硬编码） - 配置文件
config/container.php中无需额外绑定，只要类存在且构造函数可反射，php-di 会自动解析
闭包路由里想用服务？别绕开容器
闭包里不能直接 new 控制器，也不能靠属性注入。必须显式通过容器获取依赖：
- 简单场景：用
Container::get(UserService::class)直接取单例服务 - 带参构造：用
Container::make(LogService::class, [$path, $name]) - 绝对不要混用：
new UserService()+Container::get(Logger::class)会导致部分依赖失效、测试难 mock - 第三方回调（如 SDK 异步通知）中无法用容器？那就把依赖拆到方法参数传入，而不是塞进类属性
最易被忽略的一点：哪怕你把 config/container.php 配得再完美，只要在闭包路由、事件回调、定时任务里用了 new，那些 typed property 就永远等不到注入——它们根本不会被 php-di 看见。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
