Hyperf 的 @Inject 不支持递归扫描嵌套类，仅对容器管理的 Bean 触发属性注入；需确保每层依赖（如 B）均被 @Bean 注解或手动 bind 注册，否则其内部 @Inject 无效。
Hyperf 的 @Inject 默认不支持递归解析嵌套类
Hyperf 的 DI 容器在扫描 @Inject 属性时，只做一层依赖发现：它会解析当前类的属性类型，但不会自动递归扫描该类型内部是否还含有带 @Inject 的属性。也就是说，如果 A 注入了 B，而 B 内部又注入了 C，只要 B 被正确声明为 @Bean 或已注册到容器，C 就能被正常注入——但这不是“递归扫描”带来的，而是容器在实例化 B 时按需触发其自身属性注入的结果。
真正的问题在于：当 B 是一个未被容器管理的普通类（比如没加 @Bean、也没手动 $container->get() 过），Hyperf 不会主动去扫描它的属性，更不会“递归地”把它也纳入依赖图构建流程。
- Hyperf 的属性注入发生在类实例化后、方法调用前的
afterInstantiation阶段，仅对容器明确负责创建的对象生效 -
@Inject只是标记，不等价于“强制启用深度反射扫描” - 所谓“扫描范围”，实际由
BeanScan配置决定，它只控制哪些命名空间下的类会被检查是否有@Bean/@Inject等注解，不控制注入链深度
如何让嵌套类（如 B）也被容器接管并完成属性注入
关键不是开启“递归扫描”，而是确保每一层需要注入的类都成为容器管理的 Bean。否则，即使你在 B 上写了 @Inject，也不会触发任何注入逻辑。
- 给
B加上@Bean注解，并确认它落在scan.scan_dirs配置的路径内（例如App\Service） - 若
B是第三方类或无法修改源码，改用构造函数注入 + 手动绑定：$container->bind(B::class)->to(YourBImpl::class);
- 避免在非容器管理对象中使用
@Inject—— 比如在new B()实例上调用方法，此时@Inject完全无效 - Hyperf 2.2+ 支持
@Value和@Inject混合使用，但前提是宿主类本身是 Bean；嵌套类不满足该前提时，所有注解都会被忽略
调试注入失败时，优先检查 Container::has() 和日志级别
很多“注入为空”的问题，其实是类根本没进容器，而不是解析失败。直接查容器是否认得这个类，比翻反射逻辑更快。
- 在
Command或Controller中临时加一行：var_dump($this->container->has(B::class)); // false 表示未注册
- 启动时加
--vvv参数，Hyperf 会输出所有被扫描到的 Bean 类及其注入点，注意看B是否出现在列表里 - 如果
B出现在扫描日志中但属性没被注入，大概率是它的构造函数抛异常导致实例化中断，此时容器会静默跳过后续属性注入 - 不要依赖 IDE 的注解提示判断注入是否生效——PHP 运行时和静态分析是两回事
自定义扫描器不能绕过容器生命周期约束
有人尝试写个递归反射工具遍历所有 @Inject 属性并手动调用 injectProperties，这看似能“强制递归”，但极易出错：
- Hyperf 的
injectProperties方法要求目标对象必须已通过容器创建（含完整元数据），否则会报InvalidArgumentException: Invalid bean instance - 手动反射调用会跳过
beforeInstantiate/afterInstantiate等生命周期钩子，导致 AOP、事件监听等功能失效 - 循环依赖检测、作用域（Singleton/Prototype）管理均由容器统一维护，外部干预容易破坏一致性
- 真正需要深度嵌套管理的场景，建议拆成清晰的接口契约 + 显式依赖声明，而非靠扫描“猜”依赖关系
复杂嵌套本身不是问题，问题常出在某一层悄悄脱离了容器管控——盯住 Container::has() 返回值，比研究递归扫描逻辑更接近本质。
