本文详解 spring security 中如何正确配置多个自定义认证过滤器（如分别处理 get/post 请求），避免因过滤器顺序、重复授权配置或 `authorizerequests()` 分段调用导致的 401/403 错误。核心在于统一授权入口、合理使用 `addfilterbefore`/`addfilterafter`，并避免链式 dsl 的误用。
在 Spring Security 中，将多个自定义认证过滤器（如 FilterA 和 FilterB）直接通过 .addFilter() 连续追加，并配合多段 .authorizeRequests() 配置，是典型的设计误区。你遇到的现象——“第一个过滤器总失败，第二个却正常”——根本原因在于：
-
HttpSecurity 的 DSL 是状态累积型的，但 authorizeRequests() 不可重复调用生效：
每次调用 .authorizeRequests() 都会创建一个新的 ExpressionUrlAuthorizationConfigurer 实例，后续 .mvcMatchers(…).authenticated() 仅作用于该次配置块；只有最后一个 .authorizeRequests() 块的规则真正生效，前面的会被覆盖或忽略。这导致 /getrequest/** 的权限规则实际未生效，触发默认拒绝（401）。 -
过滤器注册顺序 ≠ 请求匹配逻辑顺序：
即使 FilterA 先注册，若它未成功完成认证（如未设置 SecurityContext 或抛出异常），后续过滤器（如 FilterB）仍可能被调用，但此时 SecurityContextHolder 为空，FilterB 的 authenticationManager 将无法基于已有上下文工作，极易因空 principal 或重复认证引发 403。 -
混合使用 authenticationManager() 和 authenticationProvider() 易引发委托冲突：
authenticationManager() 默认由 AuthenticationConfiguration 提供，已集成全局 AuthenticationProviders；而手动调用 .authenticationProvider(customAauthProvider()) 仅影响该配置块后的默认 manager，与 FilterB 中显式注入的 authenticationManager() 可能不一致，造成行为不可预测。
