构造函数注入必须满足：控制器由DI容器创建（如加@AutoController注解）、Service类可被自动解析（在默认扫描路径下或已接口绑定）、参数为具体类或已绑定接口类型、参数不能带干扰装配的默认值。
Hyperf控制器注入Service有明确的两种主流方式：构造函数类型声明自动注入，和@Inject注解注入。只要Service类已正确注册（默认命名空间下自动扫描），且控制器本身由DI容器创建（如@AutoController标注），就能生效。手动new出来的控制器实例不会触发任何注入。
构造函数注入必须满足哪些前提？
这是最推荐、也最符合PSR-11规范的方式，但容易因忽略前提而失败：
- 控制器类必须由Hyperf DI容器实例化——即需带
@AutoController、@Controller等注解，或显式通过$container->get(IndexController::class)获取 - Service类必须可被自动解析：类名在
App\Service\*等默认扫描路径下，且不含语法错误；若使用接口绑定，需在config/autoload/dependencies.php中配置UserServiceInterface::class => UserService::class - 构造函数参数必须是具体类或已绑定的接口类型，不能是未定义的别名或运行时才确定的字符串
- 参数不能带默认值（如
= null）除非你明确设为可选依赖，否则会干扰自动装配逻辑
@Inject注解注入的典型误用场景
很多人以为@Inject能绕过构造函数限制，其实它只是另一种注入时机，仍有严格约束：
- 属性必须是
protected或private，public属性不支持注入 - 必须配合
@var注解声明类型，例如/** @var UserService */ protected $userService;，仅写@Inject不写@var会注入失败 -
required=false仅对可选依赖有效，但若Service根本没注册进容器，仍会报NotFoundException而非静默设为null（除非你在dependencies.php里显式绑定为null） - 不适用于临时对象：用
new IndexController()创建的实例，即使加了@Inject也不会生效
为什么注入后调用方法报“Call to undefined method”？
这不是注入失败，而是注入的对象类型与预期不符。常见原因：
- Service类实现了接口，但控制器里类型提示写的是实现类（如
UserServiceImpl），而dependencies.php绑定了接口→实现类，导致容器返回的是接口类型，实际却按实现类调用 - Service类用了
final修饰，而Hyperf默认启用代理机制（用于AOP），此时会因无法生成代理类而降级为直接实例化——但若该类有非public构造参数或静态初始化问题，就可能返回空对象或异常实例 - PHP OPcache未刷新，导致旧的类定义缓存仍在，新添加的
getInfoById方法未被识别（执行php bin/hyperf.php di:scan并重启服务） - 方法名拼写错误或大小写不一致（Linux服务器区分大小写，
getinfobyid≠getInfoById）
真正容易被忽略的是：Hyperf的DI容器在协程环境下是进程级单例，所有请求共享同一份Service实例。如果你在Service里保存了请求相关状态（比如$this->userId = $request->input('id')），多个并发请求会相互覆盖。这种“伪注入成功、真逻辑错乱”的问题，比注入失败更难排查。
