如何解决Spring Boot项目中拦截器无法触发的问题

这个问题和拦截器本身的配置规范度无关，本质是Jersey与Spring MVC的请求处理链路完全隔离导致的。

组件生效范围差异说明 #

• 继承OncePerRequestFilter的组件是Servlet容器层面的过滤器，处于整个请求处理链路的最外层。无论后续请求被Spring MVC的DispatcherServlet处理，还是被Jersey的独立Servlet处理，都会先经过这层Filter链，所以Filter可以正常触发。
• 实现HandlerInterceptor的拦截器是Spring MVC专属的内部组件，仅存在于Spring MVC的DispatcherServlet处理流程中——只有当请求被路由到Spring MVC的控制器（标注@Controller/@RestController的类）时，才会触发拦截器链。

当前配置的核心冲突点：
Spring Boot的Jersey Starter默认会把Jersey的核心处理类ServletContainer注册为独立Servlet，默认映射路径为/*，会优先拦截所有进入应用的请求，直接把请求送入Jersey的处理链路，根本不会进入Spring MVC的DispatcherServlet流程。这也是为什么调整拦截器为标准格式后依然无法触发的根本原因。

落地解决方案 #

根据实际业务场景二选一即可：

方案1：拆分两个框架的路由映射范围，保留原有Spring MVC拦截器 #

给Jersey的所有接口配置统一路径前缀，避免两个框架的路由映射重叠抢请求：

1. 在项目配置文件中添加Jersey路径前缀配置：

spring.jersey.application-path=/jersey

2. 配置完成后，Jersey仅会处理/jersey/**路径下的请求，剩余非/jersey前缀的请求会正常进入Spring MVC的处理链路，原有VaultAuthorizationInterceptor就可以正常触发。

注意：严禁两个框架的Servlet映射路径完全重叠（比如同时映射/*），否则会出现后注册的Servlet永远接收不到请求的问题，Spring MVC的所有内部机制（拦截器、全局异常处理、参数校验等）都会完全失效。

方案2：全Jersey架构下替换为Jersey原生拦截组件 #

如果项目没有使用Spring MVC的控制器，所有API都由Jersey实现，那么从架构层面看Spring MVC的拦截器永远不可能生效。这时候需要使用Jersey自身的请求过滤器实现相同的鉴权逻辑：

1. 编写实现JerseyContainerRequestFilter接口的鉴权组件：

public class VaultAuthorizationJerseyFilter implements ContainerRequestFilter {
    private static final Logger logger = LoggerFactory.getLogger(VaultAuthorizationJerseyFilter.class);
    @Override
    public void filter(ContainerRequestContext requestContext) throws IOException {
        logger.info("test");
        // 鉴权不通过时直接中断请求流程
        // requestContext.abortWith(Response.status(Response.Status.UNAUTHORIZED).entity("无权访问").build());
    }
}

2. 将该过滤器注册到Jersey配置类中：

@Configuration
public class JerseyConfig extends ResourceConfig {
    public JerseyConfig(){
        packages("com.xxx");
        // 注册Jersey自定义请求过滤器
        register(VaultAuthorizationJerseyFilter.class);
    }
}

内容的提问来源于stack exchange，提问作者徐松峰