hyperf 的 aspect 类默认不由容器管理，@inject 注入失效是因为 aspectloader 通过反射“裸 new”实例，跳过了容器的 make() 流程；正确做法是在 process 方法中用 container::get() 按需获取依赖。
Hyperf 的 Aspect 类默认不是由容器自动管理的——即使你加了 @Aspect 注解，它也只被框架识别为切面定义，不会走 DI 容器的完整生命周期。所以直接在切面类里用 @Inject 注入依赖，大概率会得到 null。
为什么 @Inject 在 Aspect 类里不生效
Hyperf 的切面注册机制（AspectLoader）在扫描时仅收集类的元信息（如切点表达式、优先级），然后通过反射实例化切面类，**跳过了容器的 make() 流程**。这意味着：
-
@Inject、@Value、构造函数注入等容器特性全部失效 - 切面实例是“裸 new”出来的，没有经过属性注入或初始化回调
- 即使你手动把切面类注册进容器，也不会自动替换框架内部使用的实例
正确做法：用 Container::get() 手动获取依赖
最稳妥、官方也推荐的方式，是在切面方法中按需从容器取依赖。这不是“反模式”，而是切面场景下的合理选择——因为切面本身是无状态的工具类，依赖只是临时使用，不需要长期持有。
示例：
#[Aspect]
class DemoAspect implements AspectInterface
{
public function __construct()
{
// ❌ 不要在这里试图注入，这里不走容器
}
public function process(ProceedingJoinPoint $proceedingJoinPoint)
{
// ✅ 正确：运行时从容器取
$logger = Container::get(LoggerInterface::class);
$userService = Container::get(UserService::class);
$logger->info('Before method call');
$result = $proceedingJoinPoint->process();
$logger->info('After method call');
return $result;
}
}
- 确保目标类（如
UserService）已正确注册到容器（即有@Inject或已配置为单例） - 不要缓存
Container::get()的结果到属性里——切面实例可能被复用，但容器实例本身是线程安全的 - 如果依赖是协程安全的（比如 Hyperf 默认的
LoggerInterface），无需额外处理；否则注意是否需要ApplicationContext::get()配合协程上下文
进阶：让切面类真正由容器管理（需配合自定义 AspectLoader）
如果你确实需要切面类支持完整 DI（比如想用构造函数注入、AOP 嵌套、或依赖其他切面），就必须绕过默认的切面加载逻辑，改用容器实例化切面，并手动注册到 AspectRegister。
步骤如下：
- 在
config/autoload/aspects.php中**不注册该切面类**（避免重复加载） - 新建一个
ServiceProvider，在boot()中手动注册：
public function boot()
{
$container = $this->getContainer();
$aspect = $container->get(DemoAspect::class); // ✅ 走完整容器流程
AspectRegister::getInstance()->addAspect($aspect);
}
- 确保
DemoAspect类本身被容器扫描到（比如加@Inject或显式调用$container->set()） - 此时
@Inject、@Value、__invoke初始化等都可正常工作 - ⚠️ 注意：多个切面间若存在循环依赖，容易触发容器死锁，这类场景建议退回到
Container::get()模式
容易忽略的关键点
切面类是否“被容器管理”，和它是否“能拦截目标方法”是两件事。前者影响依赖注入能力，后者只取决于 @Aspect 和切点表达式是否匹配。很多人卡在注入失败后反复检查切点写法，其实问题根本不在那里。
另外，Container::get() 在协程环境下是安全的，但如果你在切面中启动了新协程（比如 go()），且该协程内又调用了 Container::get()，需确认目标服务是否支持协程隔离（例如 DB 连接池、Redis 连接等）。这时候不能只看注入是否成功，还要看运行时行为是否符合预期。
