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)精确控制顺序
  • 避免混用@WebFilterFilterRegistrationBean,否则行为不可预测
  • 数值越小,越早执行(如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()会导致请求中断

这是最常见也最隐蔽的问题:某个FilterdoFilter()方法中做了逻辑判断后,忘记调用chain.doFilter(request, response),结果后续所有Filter和最终的Servlet都不会执行,客户端卡住或返回空白页,日志里还看不到报错。

典型错误场景包括:

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

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

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

当某个Filter使用HttpServletRequestWrapperHttpServletResponseWrapper包装请求/响应对象后,下游Filter再试图强转为原始类型(如HttpServletRequest)会失败,抛ClassCastException

比如:

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

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

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

这意味着:

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

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