Hyperf服务类中通过构造函数注入其他服务，需确保被注入服务已由容器管理（如加@Inject注解或配置绑定），并在构造函数参数中声明具体类型；接口注入须先在dependencies.php中绑定实现。
Hyperf 服务类中如何通过构造函数注入其他服务
Hyperf 默认支持基于构造函数的依赖注入，只要目标服务已正确声明为容器可管理（即使用 @Inject 或已配置为单例/原型），就能在当前服务类构造函数中直接声明类型提示并自动解析。
常见错误是忘记给被注入的服务类添加 @Inject 注解，或未启用注解扫描（scan 配置漏掉对应命名空间）。
- 确保被注入的服务类顶部有
@Inject注解（即使它本身不依赖其他服务，也需要显式标记才能被容器识别） - 检查
config/autoload/dependencies.php中是否误写了手动绑定，覆盖了自动扫描行为 - 构造函数参数必须使用具体类名（不能是接口，除非你已手动 bind 接口到实现类）
- Hyperf 2.x+ 默认关闭
scan的ignore_annotations，但若项目中启用了该选项，@Inject会被跳过
示例：
#[Inject]
class UserService
{
public function __construct(
private OrderService $orderService, // 自动注入
private CacheInterface $cache // 也支持 PSR 接口（需已 bind）
) {
}
}
用 ApplicationContext::get() 手动获取服务是否可行
可以，但不推荐在服务类主逻辑中使用。它绕过了依赖注入的可测试性与生命周期管理，容易导致循环依赖难以排查，且破坏类型推导。
适用场景仅限于：动态服务名、运行时才确定依赖类型、或在非容器管理的对象（如 DTO、Listener 回调）中临时取服务。
-
ApplicationContext::get(OrderService::class)会触发一次容器解析，若该服务未初始化则新建；已存在则返回单例 - 若
OrderService构造函数依赖当前正在构建的服务（比如 A → B → A），手动 get 会触发无限递归，而构造注入会在容器层直接报CircularDependencyException - IDE 和静态分析工具无法追踪
get()调用，重构时容易遗漏依赖变更
为什么 @Value 注入配置后，服务类里却拿不到值
@Value 只对属性生效，且要求属性为 public 或 protected，同时类必须由容器创建（即通过 make() 或自动注入实例化）。如果服务是 new UserService() 手动 new 出来的，@Value 完全不会处理。
- 确认该服务类顶部有
@Inject，否则容器不会接管其实例化过程 -
@Value不支持构造函数参数，只能用于属性注入；且不支持类型声明（PHP 8.0+ 属性类型仍需额外判断） - 配置键名要带前缀，例如
@Value("app.name")对应config/autoload/app.php中的'name' => 'hyperf' - 若配置值为
null，@Value默认返回空字符串，不是null—— 这点容易误判为“没注入成功”
Hyperf 服务间注入失败的三个高频原因
大部分“注入为空”或“Class not found”问题都集中在环境和配置层面，而非写法本身。
- 服务类文件没放在
scan配置指定的目录下（默认是app/，但有人误放app/Services/却没更新scan.paths） - 类名与文件路径不匹配（如
UserService.php里定义了class UserServer），PSR-4 加载失败，容器根本找不到这个类 - CLI 模式下修改了服务类但没重启
server:watch或server:start --daemon，旧字节码还在运行，新注解未生效
最稳的验证方式：在命令行执行 php bin/hyperf.php di:dump，看目标服务是否出现在输出列表里。不在，说明容器压根没扫描到它。
