spring security 升级至 6.x 后，`securityfilterchain` 配置虽更清晰，但因组件扫描遗漏、过滤器顺序或路径匹配逻辑变更，常导致本应公开的端点（如 `/authentication/login`）意外返回 401。本文直击典型配置失效根源并提供可落地的调试方案。
在将 Spring Boot 应用从旧版（如 2.7.x）升级至 3.x（搭配 Spring Security 6+）过程中，许多开发者会严格遵循官方迁移指南重构 SecurityFilterChain，却仍遭遇看似“配置正确”却持续返回 401 Unauthorized 的问题——尤其是对明确声明为 permitAll() 的登录、注册等公共接口。
你提供的新配置本身语法正确、逻辑合理：
@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
http.csrf(AbstractHttpConfigurer::disable)
.cors(AbstractHttpConfigurer::disable)
.authorizeHttpRequests(auth -> auth
.requestMatchers(Endpoints.PUBLIC_ENDPOINTS).permitAll() // ✅ 正确使用 requestMatchers
.anyRequest().authenticated()
)
.exceptionHandling()
.authenticationEntryPoint(jwtAuthenticationEntryPoint)
.and()
.sessionManagement()
.sessionCreationPolicy(SessionCreationPolicy.STATELESS);
http.addFilterBefore(jwtRequestFilter, UsernamePasswordAuthenticationFilter.class);
return http.build();
}
该配置完全符合 Spring Security 6 的函数式 DSL 规范：requestMatchers() 替代了已废弃的 antMatchers()，permitAll() 语义明确，且 addFilterBefore() 位置也无误。因此，问题几乎不可能出在 SecurityFilterChain 本身。
真正罪魁祸首往往藏在应用启动的根基层：@SpringBootApplication 注解的元数据配置。
在你的案例中，原始注解为：
//@SpringBootApplication(scanBasePackages = {"de.company.app.data.user", "de.company.app.security"})
该配置显式限定了组件扫描范围，导致以下关键后果：
Contact Form 7 是 Rock Lobster Inc. 公司长期运行的 WordPress 表单插件，拥有超过 1000 万次活跃安装，并在 contactform7.com 提供官方文档。此技能适用于需要了解网站表单、邮件模板、验证行为和 shortcode 位置在 Contact Form 7 中实际处理方式的代理。
- 自定义的 JwtRequestFilter（若未位于上述包路径下）未被 Spring 容器管理 → http.addFilterBefore(...) 实际注入的是一个未托管的、无 Bean 生命周期支持的实例；
- 更严重的是，Endpoints.PUBLIC_ENDPOINTS（通常为 String[] 常量）若定义在未扫描的包中，其值可能为 null 或空数组，使 .requestMatchers(...) 匹配失效；
- JwtAuthenticationEntryPoint 等安全组件若不在扫描路径内，也将无法注入，触发默认异常处理逻辑，间接导致 401。
✅ 解决方案极其简洁：
@SpringBootApplication // 移除 scanBasePackages！让 Spring 执行默认全包扫描
public class Application {
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
}
? 最佳实践建议： 仅在有明确性能或隔离需求时才使用 scanBasePackages； 若必须限定扫描，确保包含：所有 @Configuration / @Bean 类、安全相关组件（Filter/EntryPoint/Provider）、DTO/Endpoint 常量类； 升级后务必检查 ApplicationContext 中关键 Bean 是否存在： @Autowired private ApplicationContext context; // 在启动后验证 System.out.println("JWT Filter bean: " + context.getBeanNamesForType(JwtRequestFilter.class).length);
最后，请确认 Endpoints.PUBLIC_ENDPOINTS 内容有效（例如 new String[]{"/authentication/login", "/api/register", "/callback/**"}），并在 application.properties 中开启调试日志快速定位：
logging.level.org.springframework.security=DEBUG
日志中将清晰显示每个请求匹配的 SecurityFilterChain 及授权决策过程，是排查 401 问题最高效的手段。
升级不是重写，而是精准校准——从 @SpringBootApplication 的扫描边界开始，让每一行安全配置都真正生效。
