使用@EnableWs添加自定义ValidationInterceptor致@Configuration Bean的AOP失效

这个问题我之前在项目里也碰到过类似的，核心原因确实和@EnableWs改变了Spring Bean的初始化顺序以及AOP代理的创建时机有关，具体可以拆解成这几个关键点：

1. WebService自动配置提前触发了Interceptor的初始化 #

@EnableWs会引入Spring WebService的自动配置逻辑，其中包含了一系列WebService相关的Bean（比如消息处理器、端点适配器等），这些Bean通常会被Spring标记为高优先级初始化。当你的ValidationInterceptor被这些WebService Bean依赖时，它会被提前初始化——而此时负责生成AOP代理的AnnotationAwareAspectJAutoProxyCreator（Spring AOP的核心处理器）还没来得及为你的配置类生成代理对象。最终Interceptor注入的是配置类的原始对象，而非被切面增强后的代理对象，自然触发不了切面逻辑。

2. 配置类的代理创建时机滞后于Interceptor的初始化 #

Spring的AOP代理是通过BeanPostProcessor实现的，它的执行时机是在Bean实例化完成后、初始化方法（比如@PostConstruct）执行之前。但如果你的ValidationInterceptor在AnnotationAwareAspectJAutoProxyCreator完成配置类的代理创建之前就已经完成了初始化和依赖注入，那么它拿到的配置类就是未被增强的原始实例。这种顺序颠倒的情况，正是@EnableWs引入的高优先级Bean打乱了原本的初始化流程导致的。

3. 可能存在的上下文隔离问题 #

少数情况下，@EnableWs会创建一个独立的WebService子上下文，如果你配置类的扫描范围没有覆盖到这个子上下文，或者Interceptor是在子上下文中初始化的，那么它注入的配置类可能是子上下文中的原始实例，而切面逻辑只在主上下文生效，也会导致切面无法触发。

验证与解决方向 #

• 验证初始化顺序：在你的配置类和ValidationInterceptor中添加@PostConstruct方法，打印初始化日志，确认两者的初始化先后顺序。比如：

  @PostConstruct
  public void init() {
      System.out.println("初始化：" + this.getClass().getName() + "，是否为代理：" + AopUtils.isAopProxy(this));
  }
  

• 延迟注入配置类：给ValidationInterceptor中配置类的依赖添加@Lazy注解，这样配置类的代理对象会在第一次调用其方法时才被创建，确保注入的是增强后的实例：

  @Autowired
  @Lazy
  private YourConfig yourConfig;
  

• 调整初始化优先级：给你的配置类添加@DependsOn注解，确保它在ValidationInterceptor之前完成初始化和代理创建；或者给ValidationInterceptor添加@DependsOn指向AnnotationAwareAspectJAutoProxyCreator的Bean名称（默认是org.springframework.aop.config.internalAutoProxyCreator），强制Interceptor在代理处理器就绪后再初始化。
• 检查上下文配置：确认@EnableWs的配置没有隔离上下文，确保配置类和切面都被扫描到同一个Spring上下文中。

内容的提问来源于stack exchange，提问作者hudi