WebSecurityConfigurerAdapter 被彻底移除，因其继承式配置僵化，无法支持响应式安全与模块化；替代方案是函数式配置 SecurityFilterChain，并注意 PasswordEncoder、CSRF 及路径匹配等关键变更。
为什么 WebSecurityConfigurerAdapter 被弃用了？
Spring Boot 2.7+ 和 Spring Security 6.0+ 彻底移除了 WebSecurityConfigurerAdapter，不是“不推荐”，是直接删了。继续用会编译失败，报 ClassNotFoundException 或 BeanCreationException。原因很实在：基于继承的配置方式太僵硬，无法支持响应式安全、细粒度 Bean 注入和模块化策略。
替代方案是函数式配置——用 @Bean 定义 SecurityFilterChain，配合 AuthenticationManagerBuilder（已淘汰）或独立构建 AuthenticationManager。
- 别再搜 “继承 WebSecurityConfigurerAdapter 示例”，那代码在新项目里根本跑不起来
- 如果用的是 Spring Boot 3.x，连 Servlet API 都默认不包含，必须显式加
spring-boot-starter-web -
http.authorizeHttpRequests()是新 DSL 入口，旧的authorizeRequests()已不可用
内存认证怎么写才不踩空指针？
最简内存认证看似三行完事，但漏掉 UserDetailsService 或没配 PasswordEncoder，启动就抛 NullPointerException 或登录时提示 “Bad credentials” 却不告诉你哪错了。
关键点不在“怎么加用户”，而在“谁来校验密码”。Spring Security 6 默认要求非空 PasswordEncoder，哪怕你存的是明文，也得明确说 “我真要用 NoOpPasswordEncoder”。
- 用
PasswordEncoderFactories.createDelegatingPasswordEncoder()是最稳妥的，它能自动识别 {noop}、{bcrypt} 等前缀 - 内存用户必须通过
User.withDefaultPasswordEncoder()构建（仅限开发），否则密码不会被编码，校验必失败 - 别把
InMemoryUserDetailsManager声明成@Bean后又在SecurityFilterChain里重复调inMemoryAuthentication()，会冲突
@Bean
public UserDetailsService userDetailsService() {
return new InMemoryUserDetailsManager(
User.withUsername("admin")
.password("{noop}123456") // 明文前缀必须写
.authorities("READ", "WRITE")
.build()
);
}
数据库认证连不上 JdbcUserDetailsManager 怎么查？
JdbcUserDetailsManager 不是开箱即用的全自动组件。它只负责按固定 SQL 查库，字段名、表结构、密码编码方式全要对得上，错一个就静默失败——登录页没报错，但日志里全是 BadCredentialsException。
默认查的三张表：users（username, password, enabled）、authorities（username, authority）、group_authorities（可选）。如果你用的是 sys_user 这类自定义表名，必须重写 SQL。
- 检查
DataSource是否已注入成功，@Autowired DataSource ds打个断点确认不为 null - 手动执行默认 SQL：
SELECT password FROM users WHERE username = ?，看是否真能查到数据且 password 字段非空 - 如果密码是 bcrypt 编码，确保数据库里存的是完整哈希串（如
$2a$10$...），且PasswordEncoderBean 用的是BCryptPasswordEncoder - 别忘了给
JdbcUserDetailsManager设置setDataSource(ds)，它不会自动装配
为什么登录后跳转失效或 403？
常见现象：输入正确账号密码，页面刷一下又回到登录页；或者能进首页，但点个 /api/user 就 403。问题通常不在认证逻辑，而在授权规则没覆盖请求路径，或 CSRF 配置和前端不匹配。
Spring Security 6 默认开启 CSRF（针对表单 POST），而多数前端发 JSON 请求时没带 X-CSRF-TOKEN，结果所有 POST/PUT/DELETE 都被拦。另外，静态资源（/css/**、/js/**）若没显式放行，也会被当成受保护路径拦截。
- API 项目建议关掉 CSRF：
http.csrf(csrf -> csrf.disable())，但前提是用了 token 认证（如 JWT） - 放行静态资源必须写在
authorizeHttpRequests()最前面，顺序错就无效：requestMatchers("/css/**", "/js/**").permitAll() - 登录成功后默认跳转到上次被拦截的 URL，如果没记录（比如直接访问 login 页面），就会跳
/——确保根路径有对应 controller 或配置defaultSuccessUrl("/home", true)
最常被忽略的一点：Spring Boot 的 spring.mvc.servlet.path 或自定义 DispatcherServlet 路径会影响 Security 的匹配前缀，比如设了 /api，那 requestMatchers("/user") 就永远不生效。
