Hyperf中AOP无法拦截内部方法调用，根本原因是动态代理仅作用于容器注入的代理对象调用，而this.methodB()直接调用原始实例，绕过代理层；推荐方案为拆出独立Service类、改用Middleware或手动触发逻辑。
Hyperf 中的切面（@Aspect）无法拦截类内部方法调用，不是配置错误，也不是注解漏写，而是 Spring AOP（Hyperf 默认复用其语义和代理模型）在设计上就**不支持**这种调用路径。根本原因在于代理对象未参与执行——你调的不是代理，是原始对象本身。
为什么 @Before 在 self-call 里完全不触发
Hyperf 的 AOP 基于动态代理（JDK Proxy 或 CGLIB），只对「通过容器注入、经由代理对象发起的调用」生效。当你在同一个类里写 this.methodB()，JVM 直接走的是原始实例的方法表查找，绕过了代理层，切面自然无从介入。
常见错误现象：
- 加了
@Trace或自定义注解，但日志/计时/权限校验在内部调用时完全静默 - 单元测试中手动 new 实例调用，切面失效（因为没走 DI 容器）
- 协程内多次调用同一 Service 方法，只有首次被拦截（后续仍是 this 调用）
关键点：Hyperf 的 @Aspect 不是字节码增强，它不修改 class 文件，也不重写方法调用指令。它只“守门”，不“改路”。
Hyperf 下能用的三种真实可行方案
别试图用 AopContext.currentProxy()（Spring 特有且需开启 expose-proxy，Hyperf 不支持）或反射强转代理对象——这些在 Hyperf 协程 + Swoole 环境下极易引发内存泄漏或上下文错乱。
推荐按优先级选择：
-
拆出独立 Service 类：把需要切面的方法移到另一个
@Service类中，通过@Inject调用。这是最干净、最符合协程生命周期的做法。 -
改用中间件（Middleware）：如果切面逻辑是 HTTP 请求级的（如鉴权、埋点），直接写进
Middleware，洋葱模型天然覆盖所有控制器入口，不依赖代理。 -
手动触发逻辑（慎用）：在内部调用前，显式调用一个封装好的切面逻辑函数，比如
$this->doAuthCheck();。这不是 AOP，但可控、可测、无副作用。
注意：AspectJ 字节码织入理论上可行，但 Hyperf 官方未提供开箱即用支持，且会破坏协程上下文隔离，实践中几乎没人用。
容易被忽略的协程陷阱：单例 + 内部调用 = 隐形状态污染
Hyperf 的 @Service 默认是单例，而协程共享进程内对象。如果你在内部方法里写了类似 $this->cache = $data;，这个 $cache 会被下一个协程复用——切面没拦住调用，状态却悄悄污染了。
所以重构时不止要“让切面生效”，更要检查：
- 该方法是否读写实例属性？→ 改为参数传入或 Context 存储
- 是否用了静态变量或全局数组？→ 协程间绝对不可共享
- 是否在内部调用中打开了数据库连接或 Redis 客户端？→ 必须确保每个协程独占资源
代理机制的局限性只是表象；真正危险的，是误以为“方法加了注解就自动受控”，从而放任非隔离状态在长生命周期进程中持续累积。
