@Inherited仅限类级注解的反射向上委托，不适用于方法、字段及接口；实际开发应采用显式声明、工具类遍历或Spring AnnotationUtils等可靠方案。
Java 中的 @Inherited 并不改变开发模式本身，它只在极少数场景下简化了类层级注解的反射获取逻辑——但它带来的“便利”非常有限，反而容易引发误用和设计偏差。真正影响开发模式的是对注解继承机制的正确认知与主动应对策略。
类级注解的“伪继承”需明确边界
@Inherited 仅作用于 被标注在类上（ElementType.TYPE）且本身用 @Inherited 修饰的自定义注解，且满足以下条件时，子类调用 getAnnotation() 才能拿到父类注解：
- 父类显式声明该注解，子类未重复声明同名注解
- 使用的是
Class#getAnnotation(Class)，不是getDeclaredAnnotation() - 接口、方法、字段上的同名注解完全不受影响
这意味着：它不是“让子类自动拥有父类注解”，而是“让反射查找时自动向上委托”。一旦子类自己加了同名注解，父类的就不可见了——这本质是覆盖，不是继承。
方法与字段注解无法靠 @Inherited 传递
这是最常被误解的一点：无论你是否给方法注解加上 @Inherited，子类重写方法后，都无法通过反射直接获取父类方法上的该注解。JVM 规范明确规定它对 METHOD、FIELD 等目标类型无效。
立即学习“Java免费学习笔记（深入）”；
- 例如
@DS("slave")标在接口方法上，实现类不重复声明，就不会生效 - 框架如 dynamic-datasource 的
@DS未加@Inherited，正是因为它依赖方法级语义，而该机制根本不起作用 - 想支持方法注解的“跨层级感知”，必须手动遍历继承链或改用 AOP 切入点解析
开发模式应转向显式声明 + 工具辅助
依赖 @Inherited 带来的“自动性”不可靠，实际项目中更稳健的做法是：
- 在关键抽象类或模板类中统一声明注解，要求子类显式继承并按需覆盖（如
@Transactional在 service 抽象基类上声明） - 编写通用工具类，封装向上查找逻辑：遍历
clazz.getSuperclass()直到Object，逐个调用getAnnotation() - 在 Spring 环境中，优先使用
AnnotationUtils.findAnnotation()，它已内置对继承链的支持（包括接口和超类） - 对注解驱动的行为（如数据源切换、权限校验），把解析逻辑收口到拦截器或 Advisor 中，而非依赖反射自动发现
接口注解不参与任何继承传播
Java 接口上的注解不会被实现类继承，哪怕接口方法用了 @Inherited 注解也不行。Spring 的 @RequestMapping 能“穿透”接口，是因为 Spring MVC 自己实现了查找逻辑，并非 JVM 或 @Inherited 的功劳。
- dynamic-datasource 明确不加
@Inherited，就是避免开发者误以为接口注解会生效 - 若需接口定义契约、实现类复用行为，应配合模板方法或默认方法 + 显式注解组合使用
- 接口作为 API 契约时，注解应视为文档性说明，具体执行逻辑由实现类负责声明和保障
