@inherited仅使类上注解可被子类继承,不影响方法/字段注解;代理模式通过接口或字节码生成实现行为增强,与继承无关;二者逻辑独立,常在aop中协同使用但职责分明。

@Inherited 是一个元注解,只对类上的注解生效,且仅影响子类是否“自动继承”该注解——它不作用于方法、字段或参数;而代理模式本身与继承无关,它关注的是行为的间接调用和功能增强。二者在 Java 中常被一起使用(比如 AOP 场景),但逻辑上独立:@Inherited 解决的是注解可见性传递问题,代理模式解决的是访问控制与横切逻辑织入问题。
@Inherited 的作用范围与常见误区
它仅适用于标记在 类 上的注解,并要求该注解本身用 @Inherited 修饰,同时被标注的类被其他类继承时,子类才会“拥有”该注解(通过 getAnnotation() 可获取)。它不会让子类继承父类方法上的注解,也不会让接口实现类自动获得接口上标注的注解。
- 若自定义注解未加 @Inherited,则即使父类标注了它,子类调用 getAnnotation() 也返回 null
- @Inherited 对 @Target(ElementType.METHOD) 的注解无效——方法上的注解永远不可被继承
- 它不改变运行时行为,只是影响反射 API 获取注解的结果
代理模式不依赖继承,而是依赖接口或字节码生成
静态代理要求代理类与目标类实现同一接口(或继承同一父类),但真正起作用的是“多态调用”,不是继承关系本身;动态代理(如 JDK Proxy)强制基于接口,cglib 则基于子类字节码生成——后者看似用了继承,实则绕过源码继承,是运行时生成子类,与 @Inherited 无交集。
- JDK 动态代理无法代理没有接口的类,此时 @Inherited 标在父类上,对代理过程无影响
- cglib 生成的代理类是目标类的子类,但它不读取父类上的 @Inherited 注解来决定行为,需显式通过反射去获取
- Spring AOP 默认用 JDK Proxy,只有当目标类无接口时才退化为 cglib,此时若需注解传递,得额外处理(如手动扫描父类注解)
结合使用的典型场景:AOP + 自定义注解
例如定义一个 @Log 注解,加上 @Inherited 和 @Retention(RetentionPolicy.RUNTIME),再配合代理(如 Spring 的 @Aspect),就能让子类方法在被代理执行时,依然触发日志增强——但这依赖两步:一是子类确实“继承”了该注解(@Inherited 生效),二是代理逻辑主动通过反射检查当前执行方法所属类及其父类上的注解。
- 代理中的 InvocationHandler 或 MethodInterceptor 需调用 method.getDeclaringClass().getAnnotation(Log.class),必要时向上遍历父类
- @Inherited 确保 class.getAnnotation(Log.class) 在子类上调用时不为空,简化了注解查找逻辑
- 若注解标在方法上,则无论有没有 @Inherited,都只能通过 method.getAnnotation() 获取,与继承体系无关
不建议混用的边界情况
当注解用于配置代理行为(如 @Transactional)时,Spring 并不依赖 @Inherited 实现传播——它通过解析 Bean 的实际类型、方法签名及类层次结构综合判断,@Inherited 只是辅助手段之一。盲目给自定义注解加 @Inherited,反而可能造成语义误导(比如误以为方法级注解也能继承)。
- 事务、缓存等 Spring 注解默认不加 @Inherited,因方法行为不应由继承关系决定
- 若业务需要“子类自动启用某增强”,应明确设计契约(如规定必须继承某个基类并标注注解),而非仅靠 @Inherited
- 代理对象本身是新创建的类实例,它不继承目标类的注解,所有注解检查必须面向原始目标类或其声明处
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南











