Hyperf依赖注入异常主因是配置、生命周期、注解或代理偏差；需检查@Inject是否生效、服务是否被正确扫描注册、避免new直接实例化、开启容器debug并用di:dump/di:debug验证。
Hyperf 容器依赖注入不报错，但功能异常（比如服务为空、方法调用失败、属性未注入），往往不是“没错误”，而是错误被静默吞掉或未触发预期的异常路径。核心原因通常是配置、生命周期、注解或代理机制出了偏差。
检查 @Inject 注解是否生效
Hyperf 依赖注解驱动注入，@Inject 必须写在属性上且类本身需被容器管理（如加了 @Controller、@Service 或手动注册到容器）。
- 确认目标类有正确的注解（例如
@Service()），否则不会被扫描和代理 -
@Inject属性不能是private（Hyperf 默认只注入public或protected属性；若必须 private，需配合@Autowired+ 构造函数注入） - 避免在
__construct中直接使用未初始化的$this->xxx—— 此时注入尚未完成
确认服务已正确注册进 DI 容器
即使写了 @Service，如果所在文件未被扫描，或命名空间/目录不在 scan 配置中，服务就不会注册。
- 检查
config/autoload/dependencies.php是否手动覆盖了某些绑定，导致原始类被替换或失效 - 运行
php bin/hyperf.php di:dump查看实际注册的服务列表，搜索你的类名确认是否存在 - 确保对应类文件位于
app/下且命名空间与目录结构一致（如App\Service\UserService应在app/Service/UserService.php）
留意 AOP 代理与构造时机问题
Hyperf 使用代理类实现依赖注入和 AOP，若类被 new 直接实例化（而非通过 Container::get() 或注解自动解析），则不会触发注入。
- 禁止在代码中写
new UserService()—— 改用$this->container->get(UserService::class)或@Inject - 若类含
__construct且参数非默认值，而你又没配dependencies.php显式绑定构造参数，容器将无法实例化，可能静默返回null或抛出EntryNotFoundException（但被中间件/异常处理器捕获后未打印） - 开启调试：在
config/autoload/exceptions.php中确保ExceptionHandler没屏蔽ContainerException类异常
启用容器调试与日志追踪
Hyperf 默认不输出 DI 过程细节，需主动开启。
- 在
config/autoload/container.php中设置'debug' => true，让容器在解析失败时抛出更明确异常 - 临时在关键位置加日志：
var_dump($this->userService ?? 'null');或Logger::info('UserService instance', ['obj' => get_class($this->userService ?? 'none')]); - 使用
php bin/hyperf.php di:debug YourServiceClass查看该类的依赖图谱和注入路径
不复杂但容易忽略，关键在验证“是否真被容器管理”和“注入时机是否合理”。先跑 di:dump 和 di:debug，比盲改代码更高效。
