webman默认不启用自动依赖注入，需显式配置php-di；闭包路由、手动new实例、php 8+非空类型属性三类场景最易触发注入失败或typed property must not be accessed before initialization报错。
Webman 默认不启用自动依赖注入，必须显式配置 php-di 才能支持构造函数或属性注入；闭包路由、手动 new 实例、PHP 8+ 的非空类型属性（private Service $service）这三类场景最容易触发注入失败或报错。
闭包路由里用不了属性注入，必须改构造函数或显式获取
闭包路由（如 Route::get('/user', fn() => ...)）完全绕过框架的控制器实例化流程，php-di 根本没机会执行属性赋值。哪怕你写了 #[Inject] 或 private UserService $user，访问时直接抛 Typed property must not be accessed before initialization。
- 正确做法是：把逻辑移到控制器方法里，用标准路由写法
Route::get('/user', [UserController::class, 'index']) - 如果非得在闭包里用服务，就别依赖自动注入，改用
Container::get(UserService::class)显式拉取 - 不要在闭包里
new UserController()再调方法——这等于自己造了个“孤儿对象”，容器全程失联
构造函数注入能用，但 PHP 8+ 属性注入常报错的原因
PHP 8 引入的非空类型属性（private Mailer $mailer）要求属性在读取前必须已被赋值。而 php-di 的属性注入是“对象创建后反射写入”，存在一个时间差：如果构造函数末尾就调 $this->mailer->send()，此时属性还没来得及注入，就会崩。
- 临时调试可改成 nullable：
private ?Mailer $mailer = null，但生产环境不推荐 - 更稳妥的是彻底放弃属性注入，统一用构造函数注入——它在 new 阶段就完成所有依赖装配，无时机问题
- 确认你装的是
php-di/php-di:^7.0，低版本不支持 PHP 8 属性注入
手动 new 实例时依赖注入不生效，必须走 Container::get()
很多人配完 config/container.php 就以为“全局自动注入”了，结果在 service 或 job 里写 new OrderService()，发现日志、数据库连接全为 null。这是因为 new 是 PHP 原生操作，和容器毫无关系。
- 无参构造：用
Container::get(OrderService::class) - 需传参构造：用
Container::make(LogService::class, [$path, $name]) - 切勿混用
new和Container::get()—— 一旦某处漏掉容器，整个依赖链就断了，后续替换、Mock、测试都会卡住
容器配置生效但某些类仍不被注入？检查类是否被框架托管
webman 只对它自己创建的对象做自动注入：控制器、中间件、事件监听器、命令类。你自己在 app/job/ 或 app/service/ 里写的普通类，即使命名规范、路径正确，也不会被自动解析。
- Job 类要继承
support\Job并通过Job::dispatch()投递，才能触发注入 - Service 类若需自动注入，建议只在控制器或中间件中由容器创建；业务逻辑层尽量保持无状态，依赖通过参数传入
- 第三方 SDK 回调里无法控制对象创建方式？那就别让它持依赖，把
Mailer当方法参数传进去，而不是塞进属性里
最易忽略的一点：自动注入只发生在“对象由框架或容器创建”这个前提下。一旦脱离这个上下文（闭包、new、第三方回调、单元测试里的手动实例化），注入就失效——这不是配置问题，而是机制边界。别试图在边界外硬推注入，该显式获取就显式获取，该重构接口就重构接口。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
