多层注解嵌套应聚焦业务语义而非结构遍历，优先用getdeclaredannotationsbytype()和annotatedelementutils精准提取目标信息，对嵌套注解懒加载并缓存，组装逻辑交由解析器而非注解本身。
多层注解嵌套（如 Java 中 @RequestMapping 嵌套在 @RestController 下，或自定义注解中包含其他注解类型）会让反射获取元数据变得复杂。关键不是“层层遍历”，而是明确目标、按需提取、避免盲目递归。
明确你要提取的“最终信息”而非“注解结构”
很多问题源于混淆了“解析注解”和“获取业务语义”。比如想获取某个 Controller 方法的完整访问路径，真正需要的是：类级路径 + 方法级路径 + HTTP 方法，而不是把所有注解对象一层层 toString 出来。
- 先定义输出契约：例如返回一个
ApiInfo(path="/user", method="GET", version="v1") - 再反推哪些注解字段参与计算：如
@RequestMapping.value()、@GetMapping的隐式 method、@ApiVersion("v1")自定义属性 - 跳过不相关注解（如
@Deprecated、@SuppressWarnings），不为“完整性”而解析
用 getDeclaredAnnotationsByType() 替代手动遍历
Java 8+ 提供了更精准的注解查找方式，能自动处理重复注解、容器注解（如 @Repeatable）、以及注解中的注解（即嵌套注解类型）。
-
method.getAnnotation(RequestMapping.class)只取第一个，可能漏掉组合注解（如@GetMapping） -
method.getDeclaredAnnotationsByType(RequestMapping.class)会合并显式@RequestMapping和由@GetMapping等派生出的等效信息 - 对自定义嵌套注解（如
@ApiDoc(params = @Param(name="id"))），直接调用apiDoc.params().name()即可，无需反射读取params字段再解析其 class
对“注解里的注解”做懒加载与缓存
当注解 A 的某个属性是注解 B 类型（如 @Retryable(on = RuntimeException.class, backoff = @Backoff(delay = 1000))），B 的实例在运行时才生成，且每次调用 backoff() 都可能新建对象。
- 不要在循环中反复调用
anno.backoff().delay()；提取后存入本地变量 - 若需多次复用嵌套注解内容（如统一日志打印所有重试配置），建议封装为不可变 DTO，首次访问时解析并缓存
- 注意：注解属性值必须是编译期常量，所以
@Backoff(delay = ${retry.delay:1000})这种 SpEL 表达式需配合 Spring 的AnnotatedElementUtils或StandardAnnotationMetadata解析
借助 Spring 的 AnnotatedElementUtils 处理继承与组合
原生反射不处理注解继承（如接口方法上的注解不会被实现类方法反射到）、也不识别组合注解（如 @GetMapping 是 @RequestMapping(method = GET) 的快捷方式）。Spring 提供了更健壮的工具：
-
AnnotatedElementUtils.findMergedAnnotation(method, RequestMapping.class)：自动合并类/方法/接口/父类上的同名注解，并展开组合注解 -
AnnotatedElementUtils.getMergedAnnotationAttributes(..., "value")：直接读取指定属性，支持别名（如@GetMapping("xxx")的 value 映射到 RequestMapping 的 path） - 对自定义注解，只要标注
@AliasFor，也能被正确识别和合并
不复杂但容易忽略：多数嵌套解析问题，其实卡在没分清“谁该负责组装语义”——注解只存原始声明，组装逻辑应放在解析器里，而不是试图让注解自己“懂业务”。
