Hyperf依赖注入报错“must not be accessed before initialization”本质是AOP代理类未生成或加载失败，导致容器返回未初始化的空壳对象；常见原因包括symfony/finder升级跳过扫描、scan.paths配置遗漏切面路径、未注册AspectContainer及hyperf/aop与di版本不兼容。
Hyperf依赖注入报错，大概率是AOP代理类没生成或加载失败，不是代码写错了。
为什么#[Inject]会报“must not be accessed before initialization”
这个错误本质是容器试图访问一个还没完成初始化的代理对象。Hyperf在启用AOP时，会对被#[Inject]标记的类生成代理类（位于runtime/container/proxy/），再由DI容器返回该代理实例。如果代理类缺失或过期，容器就会返回一个未初始化的空壳，调用其属性时就炸了。
- 最常见诱因：执行过
composer update，尤其是升级了symfony/finder到 v7.0.0+，导致扫描器跳过app/目录，代理类压根没生成 - 次要诱因：清缓存后没重启服务，或
runtime/container目录权限不对，写入失败 - 隐藏诱因：切面类（
App\Aspect\*）和被注入类（如App\Service\*）不在config/autoload/annotations.php的scan.paths里，容器根本“看不见”它们
怎么确认代理类是否生成成功
别猜，直接看文件：
- 检查目录：
runtime/container/proxy/下是否有对应类名的PHP文件，比如App_Aop_AopService.php、App_Controller_AopController.php - 如果没有，运行
php bin/hyperf.php di:proxy:generate强制重生成（注意：该命令要求scan.paths配置正确） - 如果有但内容为空或只有
<?php，说明扫描阶段出错，重点查symfony/finder版本和scan.paths路径拼写（Windows下路径分隔符易出错）
构造函数注入和AOP一起用时的坑
构造函数注入本身没问题，但一旦目标类又被AOP切面拦截（比如加了#[Aspect]或被@annotation匹配），就容易触发循环依赖或代理顺序错乱。
- 避免在构造函数里直接调用另一个也启用了AOP的依赖，例如
UserService里__construct中调$this->cache->get()，而CacheService又有@Trace注解 - 如果必须这么做，把AOP切面规则从
execution(* App\Service\*.*)收紧为具体方法，避开构造函数（构造函数无法被AOP拦截，但它的调用链可能触发） - 临时绕过方式：对构造函数参数显式绑定接口，而非具体类，在
config/autoload/dependencies.php里写死实现，减少运行时反射压力
真正要盯住的三个配置点
90%的注入+AOP问题，都卡在这三处，改完立刻见效：
-
config/autoload/annotations.php里的scan.paths必须包含App\Aspect和App\Aop（或你放切面/被注入类的实际命名空间路径），不能只写App -
config/autoload/dependencies.php里必须注册Hyperf\Aop\AspectContainer::class，漏了这行，所有#[Aspect]类都不会被加载 -
composer.json中hyperf/aop版本需与hyperf/di一致，v3.4.x系列不兼容v3.3.x的代理生成逻辑
代理类生成是Hyperf运行时的“隐性契约”，它不报错，但一断就全崩。每次更新依赖或新增切面，先盯runtime/container/proxy/有没有新文件，比翻日志快十倍。
