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，顺序由<filter-mapping></filter-mapping>在文件中的排列先后决定；如果用@WebFilter注解，必须配合@ServletComponentScan（Spring Boot默认启用），但此时顺序不可控——JVM加载类的顺序不确定，容易出问题。
实际项目中更推荐显式配置：
- Spring Boot用户优先用
FilterRegistrationBean，通过setOrder(int)精确控制顺序 - 避免混用
@WebFilter和FilterRegistrationBean，否则行为不可预测 - 数值越小，越早执行（如
ORDER_HIGHEST_PRECEDENCE = -2147483648）
@Bean
public FilterRegistrationBean<LoggingFilter> loggingFilter() {
FilterRegistrationBean<LoggingFilter> 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链，两套机制嵌套，调试时务必分清入口点。
