Java过滤器链式调用_多个Filter链式执行流程与配置

Filter执行顺序由web.xml中filter-mapping顺序或FilterRegistrationBean的setOrder()控制，@WebFilter配合@ServletComponentScan时顺序不可控；doFilter()中必须调用chain.doFilter()一次且仅一次，否则请求中断；包装类需逐层unwrap避免ClassCastException；Spring Security通过FilterChainProxy统一调度多条子链，自定义Filter应置于其前。

Filter链的执行顺序由web.xml或@ServletComponentScan决定

Java Web中多个Filter的执行顺序不是按代码书写顺序，而是由部署描述符或注解扫描机制控制。如果你用web.xml，顺序由在文件中的排列先后决定；如果用@WebFilter注解，必须配合@ServletComponentScan（Spring Boot默认启用），但此时顺序不可控——JVM加载类的顺序不确定，容易出问题。

实际项目中更推荐显式配置：

• Spring Boot用户优先用FilterRegistrationBean，通过setOrder(int)精确控制顺序
• 避免混用@WebFilter和FilterRegistrationBean，否则行为不可预测
• 数值越小，越早执行（如ORDER_HIGHEST_PRECEDENCE = -2147483648）

@Bean
public FilterRegistrationBean loggingFilter() {
    FilterRegistrationBean registration = new FilterRegistrationBean<>();
    registration.setFilter(new LoggingFilter());
    registration.setOrder(1);
    registration.addUrlPatterns("/*");
    return registration;
}

doFilter()里不调用chain.doFilter()会导致请求中断

这是最常见也最隐蔽的问题：某个Filter在doFilter()方法中做了逻辑判断后，忘记调用chain

.doFilter(request, response)，结果后续所有Filter和最终的Servlet都不会执行，客户端卡住或返回空白页，日志里还看不到报错。

典型错误场景包括：

• 权限校验失败后只写response.sendError(403)，没return且没调用chain.doFilter()
• 日志Filter在捕获异常后直接return，跳过了chain.doFilter()
• 使用AsyncContext时误以为不需要继续链式调用

正确做法是：只要不打算终止流程，就必须确保chain.doFilter()被调用一次且仅一次。

Filter链中request/response包装类需注意类型向下转型

当某个Filter使用HttpServletRequestWrapper或HttpServletResponseWrapper包装请求/响应对象后，下游Filter再试图强转为原始类型（如HttpServletRequest）会失败，抛ClassCastException。

比如：

• A过滤器包装了request为MyRequestWrapper
• B过滤器里写HttpServletRequest req = (HttpServletRequest) request; → 崩溃
• 应改用HttpServletRequest req = (HttpServletRequest) ((HttpServletRequestWrapper) request).getRequest();逐层unwrap
• 更稳妥的做法是：只在真正需要修改请求体或响应体时才包装，并尽量减少包装层级

Spring Security的FilterChainProxy本质是“过滤器之过滤器”

如果你在Spring Security项目里看到一堆Filter没在web.xml或FilterRegistrationBean里配置，别慌——它们是被FilterChainProxy统一托管的。这个代理本身是一个Filter，注册在容器最外层，内部维护多条子链（如AntPathRequestMatcher匹配不同URL路径），每条子链又是一组Security Filter（UsernamePasswordAuthenticationFilter、ExceptionTranslationFilter等）。

这意味着：

• 你自定义的普通Filter和Security Filter不在同一调度平面，顺序要分开考虑
• 通常建议你的Filter放在FilterChainProxy之前（order值设得比SecurityProperties.DEFAULT_FILTER_ORDER = 0更小）
• 不要试图在Security Filter链内部插入自定义逻辑，应通过SecurityConfigurer或OncePerRequestFilter扩展

链式调用的复杂性在这里集中爆发：既有容器级Filter链，又有框架级Filter链，两套机制嵌套，调试时务必分清入口点。