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 FilterRegistrationBeanloggingFilter() { 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。
立即学习“Java免费学习笔记(深入)”;
比如:
- 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链,两套机制嵌套,调试时务必分清入口点。










