Hyperf切面需通过@Repeatable声明注解并注册容器注解类，再调用getAnnotations()获取全部实例；须检查scan.paths配置确保注解被扫描，遍历时明确合并策略（如AND语义），避免逻辑覆盖或性能损耗。
Hyperf中切面如何获取方法上的多个同类注解
Hyperf 的 @Aspect 切面默认只通过 $annotation->getAnnotation() 拿到单个注解实例，但实际场景里常需处理重复注解（如多个 @RateLimit 或自定义的 @Permission），这时必须主动启用「重复注解支持」。Hyperf 默认不开启该特性，否则 getAnnotations() 返回空数组或仅首项。
关键点：注解类本身要声明 @Repeatable，且容器中需注册对应注解解析器。否则即使写了多个，框架也只识别第一个。
- 在注解类顶部添加
@Repeatable，并指定容器注解类（如@Permissions） - 容器注解类（如
Permissions）需用@Annotation标记，并定义value: array字段接收多个子注解 - 切面中改用
$annotation->getAnnotations(Permission::class)获取全部实例，而非getAnnotation()
遍历多个注解时如何避免重复执行或逻辑覆盖
常见错误是把多个注解当成独立条件叠加判断，结果出现权限校验被绕过、限流阈值取最小值却误取最大值等问题。Hyperf 切面中每个 @Around 方法只执行一次，但内部逻辑需明确「合并策略」。
例如处理多个 @Permission 注解时，应默认采用「全满足」语义（AND），而非「任一满足」（OR）；而多个 @TagCache 可能需要合并 key 前缀而非覆盖。
- 用
array_map提前提取各注解字段，再统一决策，避免在循环内直接return中断流程 - 对数值型配置（如
limit,timeout），显式约定策略：min()用于限流，max()用于缓存过期时间 - 若需 OR 逻辑（如多角色任一匹配），应在注解字段中显式加
mode="or"参数，不依赖遍历顺序
切面中调用 getAnnotations() 返回空数组的典型原因
不是代码写错了，大概率是注解未被扫描进容器。Hyperf 的注解反射依赖 AnnotationCollector，而它只加载 scan 配置中声明的命名空间下的注解类。
即使注解类存在、也加了 @Annotation，只要没被扫描，getAnnotations() 就永远为空——这个坑在开发自定义注解时高频出现。
- 检查
config/autoload/annotations.php中的scan→paths是否包含你的注解类所在目录（如app/Annotation） - 确认注解类 use 的
Hyperf\Di\Annotation\Inject等基础注解已正确引入，否则反射失败静默跳过 - 运行
php bin/hyperf.php gen:annotation强制刷新注解缓存，尤其在新增注解后 - 调试时可用
var_dump(AnnotationCollector::getClasses())查看当前已注册的注解类列表
性能敏感场景下批量注解处理的注意事项
每次请求都遍历注解并做多次反射调用，在高并发接口中会成为瓶颈。Hyperf 虽有注解缓存，但 getAnnotations() 仍涉及对象创建和属性读取，不可忽视。
真实压测中发现，10 个同类型注解 + 每次都 new 条件对象，QPS 下降约 12%。优化核心是「提前计算、延迟触发」。
- 在切面
__construct()或静态属性中预编译注解规则（如正则、白名单数组），而非每次process()时解析 - 对纯配置型注解（如
@Log(level="debug")），用isset($this->cachedRules[$methodKey])缓存结果 - 避免在注解遍历中调用 IoC 容器
get()，改用构造注入所需服务，防止循环依赖或延迟初始化开销
最易被忽略的是注解继承问题：父类方法上的注解默认不会被子类重写方法继承，哪怕子类没加任何注解。如果业务要求「子类自动叠加父类注解」，必须手动调用 ReflectionClass::getParentClass() 向上查找，Hyperf 不做自动合并。
