Hyperf控制器构造函数注入依赖需显式使用@Inject注解，仅靠PHP8类型提示无法自动注入；必须标注@Inject并赋值，否则报类不存在或空对象错误。
Hyperf 控制器构造方法注入依赖的写法
Hyperf 的控制器构造方法注入和 Laravel 类似，但必须配合 @Inject 注解或容器自动解析规则，否则会报 Target class [xxx] does not exist 或空对象问题。
核心原则：Hyperf 默认不扫描构造函数参数类型自动注入（除非开启 scan_cacheable 且类被正确标注），必须显式声明依赖来源。
- 使用
@Inject注解标记需要注入的属性，然后在构造函数中赋值 —— 这是最稳妥、最推荐的方式 - 不能只靠 PHP 8+ 的构造函数参数类型提示（如
public function __construct(SomeService $service)）就指望自动注入，Hyperf 不默认启用 PHP 层级的构造器反射注入 - 如果类已通过
@Inject注入了属性，构造函数里仍可接收同类型参数，但需确保该参数也带@Inject或由容器能识别其来源（例如是单例、已绑定接口实现）
// app/Controller/IndexController.php
<?php
namespace App\Controller;
use Hyperf\HttpServer\Annotation\Controller;
use Hyperf\HttpServer\Annotation\GetMapping;
use App\Service\UserService;
#[Controller]
class IndexController
{
#[Inject]
protected UserService $userService;
public function __construct()
{
// 构造函数里不建议放业务逻辑，更不要试图在这里直接用 $this->userService
// 因为 @Inject 属性注入发生在构造函数执行之后（DI 容器先 new 再 set）
}
#[GetMapping("/user")]
public function getUser()
{
return $this->userService->getById(1);
}
}
为什么构造函数参数不加 @Inject 就注入失败
Hyperf 的 DI 容器默认使用「属性注入」优先策略，构造函数参数仅在以下情况才被尝试解析：
- 类本身被
@Inject标注（如作为其他服务的依赖）且构造函数参数类型是容器中已绑定的类/接口 - 配置了
scan_cacheable = false并启用了完整 AST 扫描（不推荐，影响启动速度） - 手动在
config/autoload/dependencies.php中显式绑定了接口与实现
常见错误现象：Fatal error: Uncaught TypeError: App\Controller\IndexController::__construct(): Argument #1 ($userService) must be of type App\Service\UserService, null given —— 这说明容器没给构造函数传参，而是留了 null。
想在构造函数里直接接收依赖，该怎么写
可以，但必须让容器知道这个参数要从哪来。两种可靠方式：
- 用
@Inject注解标注构造函数参数（Hyperf 3.0+ 支持）：
public function __construct(#[Inject] protected UserService $userService)
{
}
- 或在
dependencies.php中提前绑定，再靠类型自动解析（适合接口多实现场景）：
// config/autoload/dependencies.php
return [
'App\Service\UserServiceInterface' => 'App\Service\UserService',
];
此时控制器可写为：public function __construct(UserServiceInterface $service)，无需额外注解。
构造注入 vs 属性注入的实际影响
构造注入会让对象在创建时就持有不可变依赖，利于单元测试和明确契约；属性注入则更灵活，但可能在方法调用前忘记初始化。
- Hyperf 中两者性能差异极小，因为都是容器统一管理生命周期
- 构造注入对 IDE 自动补全更友好（PHPStan / Psalm 能更好推断类型）
- 若依赖是协程安全的单例（如
RedisFactory、Db），两种方式都 OK；但如果是每次请求新建的对象（如Request），Hyperf 会按作用域自动处理，无需手动干预
真正容易被忽略的是：Hyperf 的构造函数注入不触发 __get() 或魔术方法，也不支持 __call() 拦截注入过程 —— 所有依赖必须是容器能直接 new 出来或已 bind 的，否则就会卡在实例化阶段。
