spring mvc中拦截器与过滤器属不同机制，执行顺序固定：请求→filter→dispatcherservlet→interceptor→controller→响应；拦截器顺序由addinterceptor调用顺序决定，过滤器顺序由web.xml或@webfilter的order控制。
Spring MVC 中没有“通过配置拦截器链来控制过滤器执行顺序”的做法，因为拦截器（Interceptor）和过滤器（Filter）是两类不同机制、不同生命周期的组件，不能混用或统一配置在同一个链里。
拦截器和过滤器根本不在同一层
Filter 是 Servlet 规范的一部分，在请求进入 Spring 容器前就已生效，由容器（如 Tomcat）管理；Interceptor 是 Spring MVC 框架级组件，只作用于 DispatcherServlet 分发后的 Controller 方法调用阶段。
它们的执行顺序固定为：
- 客户端请求 → Filter（doFilter）→ DispatcherServlet → Interceptor（preHandle）→ Controller
- Controller 返回 → Interceptor（postHandle）→ View 渲染 → Interceptor（afterCompletion）→ Filter（doFilter chain 继续）→ 响应返回
多个拦截器的顺序靠注册先后决定
如果你要控制的是多个 Interceptor 的执行顺序，关键在于 Java 配置类中 addInterceptor() 的调用顺序：
- preHandle()：按添加顺序依次执行（I1 → I2 → I3）
- postHandle() 和 afterCompletion()：按添加的逆序执行（I3 → I2 → I1）
- 任一 preHandle 返回 false，后续拦截器全部跳过
示例配置：
@Override
public void addInterceptors(InterceptorRegistry registry) {
registry.addInterceptor(new LogInterceptor()).addPathPatterns("/**");
registry.addInterceptor(new AuthInterceptor()).addPathPatterns("/api/**");
registry.addInterceptor(new CacheInterceptor()).addPathPatterns("/data/**");
}
这里 LogInterceptor 最先执行 preHandle，CacheInterceptor 最后执行 preHandle，但最先执行 afterCompletion。
多个过滤器的顺序靠 web.xml 或 @WebFilter 的 order 控制
Filter 的顺序不由 Spring MVC 管理，而是由 Servlet 容器决定：
- XML 方式（web.xml）：按
<filter-mapping></filter-mapping>出现顺序执行 - 注解方式（@WebFilter）：用
order = Ordered.HIGHEST_PRECEDENCE或具体数值（如order = 1）显式指定优先级 - Spring Boot 中还可通过
@Bean注册 Filter 并实现Ordered接口或加@Order注解
别把两者写反或强行桥接
常见误区包括：
- 试图在
WebMvcConfigurer.addInterceptors()里注册 Filter —— 不支持，会编译报错 - 以为
mvc:interceptorsXML 标签能配 Filter —— 它只认 HandlerInterceptor 实现类 - 在 Filter 里手动调用 Interceptor 方法 —— 违背设计原则，破坏职责分离
需要协同时，建议职责分明：Filter 做编码、跨域、安全头等底层处理；Interceptor 做登录校验、日志埋点、权限控制等业务相关逻辑。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
