直接说结论如果你现在用的是 Spring Boot 3 Spring Security 6不把官网文档当主要参考资料只靠搜博客、翻旧帖子、抄历史代码那踩坑几乎是必然的。Spring Security 6 就像是把以前那套“继承一个适配器、覆写几个方法”的玩法彻底掀了桌子全新的 SecurityFilterChain 风格、Lambda DSL、authorizeHttpRequests、requestMatchers让很多人一升级编译就红一片。这篇文章我想把啃官网文档的经历、Spring Boot 3 里配置迁移的关键差异、以及我自己实操中踩过的坑全部摊开讲帮助刚接触或者正在迁移的同学少走点弯路。这篇文章也适合想正儿八经理解“认证和授权到底怎么在过滤器链里跑起来”的开发者哪怕你没做过完整的登录系统只要用过 Spring Boot 写接口跟着下面的思路走一遍基本能在脑子里搭起一个清晰的地图。1. Spring Security 官网文档到底该怎么读很多人一上来直接翻官网首页看到一坨术语和架构图就懵了。我刚开始也是这样感觉每一个单词都认识串在一起就是不知道在说什么。后来发现读 Spring Security 官网是有顺序的你按照它的逻辑段落去啃比乱翻快得多。1.1 先搞清楚你该看哪个版本官网现在默认展示的是最新版文档可能是 6.x 甚至 7.x 的预览内容。但大多数业务项目现在分布在 Spring Boot 2.7、3.0、3.1、3.2 这些版本线上。Spring Security 5.7 和 5.8 是 Spring Boot 2.x 时代的重要版本Spring Security 6.0 才是 Spring Boot 3.x 的地基。所以打开文档后第一件事是确认左上角版本。很多迁移问题查了半天结果参考的是隔壁版本的写法要么缺依赖要么 API 已经挪了包。判断标准其实很简单看你的 Spring Boot 版本。Spring Boot 3.0 对应 Spring Security 6.0Spring Boot 3.1 对应 6.1Spring Boot 3.2 对应 6.2以此类推。版本先对上后面的阅读才谈得上有效。1.2 官网文档的主体骨架是什么样的官网分了很多模块但真正核心的集中在两个大区一个是 “Getting Started”入门另一个是 “Servlet Application” 下的核心章节。对大多数人来说不需要把整本手册背下来你应该优先读这些内容Getting Started 里的 “Securing a Web Application”快速体验一个最小可跑的示例先建立“原来配置完就能自动弹登录框”的体感。Servlet Application 里的 “Architecture”讲过滤器链、SecurityFilterChain、AuthenticationManager 这一类顶层架构。这一节可以让你理解为什么 Spring Security 不是靠拦截器一个个硬编码而是由过滤器按顺序协作。“Authentication” 目录重点看 Username/Password Authentication这里面详细讲了 DaoAuthenticationProvider、UserDetailsService、PasswordEncoder 的协作关系。“Authorization” 目录看 Authorization Architecture 和 Method Security搞清楚授权决策是怎么从过滤器链一路落到方法级别的。我阅读的顺序是先过一遍 Architecture 看懂整体流程再利用 Getting Started 的示例跑起来最后针对我要用的功能表单登录、数据库账号、接口权限去查对应的章节。官网的检索功能不太给力建议多用浏览器内查找直接搜关键词比如 “PasswordEncoder”、“CSRF”、“authorizeHttpRequests”。1.3 为什么不能只看中文博客中文社区关于 Spring Security 的教程非常多但很多文章是基于 Spring Boot 2 甚至更早的写法。你可以拿来理解概念但照着敲代码会出问题。最典型的例子就是 WebSecurityConfigurerAdapter在 Spring Security 5.7 之后已经被弃用在 6.0 版本直接移除了。我见过很多同学把旧教程里的类原封不动粘到 Spring Boot 3 项目里结果编译都不通过。官网文档是唯一会跟着版本持续修正接口和示例的地方所以正确的姿势是中文博客快速理解原理官网文档确认最新写法最后用自己的项目做实验验证。2. 迁移到 Spring Boot 3 前后的核心概念差异Spring Boot 3 的迁移表面上是一堆依赖坐标从 javax 改成 jakarta实际上 Spring Security 这边的变化跟 API 风格关系更大。把这几个概念对照起来搞通旧代码迁移就不会变成猜谜游戏。2.1 WebSecurityConfigurerAdapter 与 SecurityFilterChain 的本质区别老版本里写配置几乎是固定套路Configuration EnableWebSecurity public class SecurityConfig extends WebSecurityConfigurerAdapter { Override protected void configure(HttpSecurity http) throws Exception { http .authorizeRequests() .antMatchers(/public/**).permitAll() .anyRequest().authenticated() .and() .formLogin(); } }注意代码里有很多 .and() 把不同配置区域串起来这是老式流畅风格最令人头大的地方。到了 Spring Security 5.8 / 6.0官方推荐的写法是使用 SecurityFilterChain BeanBean public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception { http .authorizeHttpRequests(auth - auth .requestMatchers(/public/**).permitAll() .anyRequest().authenticated() ) .formLogin(form - form.loginPage(/login).permitAll()); return http.build(); }两者在底层上并不是完全对立的SecurityFilterChain 这个方法本身就返回一个过滤器链而原来的继承方式本质上也是配置了一个 FilterChainProxy 内部使用的过滤器链。区别在于前者是声明式地把配置暴露成普通 BeanSpring Boot 自动注册后面可以按需定义多个 SecurityFilterChain Bean解决不同路径需要不同安全规则的问题后者是类继承一个应用往往只能有一个全局配置类改动起来很拧巴。这个迁移的核心动作并不复杂把 extends WebSecurityConfigurerAdapter 去掉把 public class 改成带 Bean 的方法把覆写方法的逻辑平移到方法体里注意各个配置段都不再用 .and() 连接而是通过 Lambda DSL 传入各自的作用域。2.2 请求匹配规则的变化antMatchers 换成 requestMatchers在 Spring Security 6 里antMatchers、mvcMatchers、regexMatchers 这些旧方法都已经被替代为各种 requestMatchers 重载。这一变化让很多人觉得费解不都是指定路径吗换名字有什么意义核心原因是 Spring Security 抽象出了 RequestMatcher 接口不同实现分别处理 Ant 风格、MVC 风格、正则风格甚至可以自定义匹配逻辑。新 API 统一叫 requestMatchers但允许你通过传参区分行为例如.requestMatchers(/api/**).permitAll() // Ant 风格 .requestMatchers(HttpMethod.POST, /api/users).permitAll() // 限定方法实际迁移时最简单的办法是全局替换。如果是简单的路径匹配直接把 antMatchers 改成 requestMatchers 就行如果用了 mvcMatchers通常也直接替换成 requestMatchers大部分场景下行为一致。但要注意授权配置里如果用的是多个匹配组合尽量把更具体的规则写在前面Spring Security 会按声明顺序逐个匹配一旦命中就不再往下判断。2.3 Lambda DSL 为什么成为唯一推荐写法Spring Security 官方迁移指南里有一个很显眼的建议所有配置都改写为 Lambda DSL。所谓 Lambda DSL 就是每个配置区域接收一个 Customizer 函数比如http .csrf(csrf - csrf.disable()) .formLogin(form - form.loginPage(/login).permitAll()) .logout(logout - logout.logoutSuccessUrl(/));旧写法是通过 .and() 把配置项串联起来。如果你维护过一个大型安全配置类就会知道.and() 链式调用很容易让人迷失当前到底在配置哪个区域。Lambda DSL 的好处是每个 lambda 的参数名称就代表当前区域作用域完全隔离不会串状态。我当时迁移最深刻的体会是以前想关闭 CSRF就写 http.csrf().disable()现在得写 http.csrf(csrf - csrf.disable())。看着只是多包了一层 lambda但带来的可读性和类型安全是实打实的。如果不小心把别的配置写进 lambda 里编译阶段就能发现错误比运行时才炸出来强太多了。2.4 认证流程里的几个隐藏角色官网文档里有一张经典架构图讲认证流程中的关键组件协作关系。我用自己的理解重新捋一遍方便记用户提交表单后请求会经过 UsernamePasswordAuthenticationFilter。该过滤器会把表单里的用户名和密码包装成一个 Authentication 对象然后交给 AuthenticationManager。AuthenticationManager 本身不直接干活它遍历所有注册好的 AuthenticationProvider找能处理当前认证方式的那种 Provider。最常用的 DaoAuthenticationProvider 会从 UserDetailsService 里取出用户资料再用 PasswordEncoder 对比密码是否一致。全部通过后成功后的 Authentication 对象被塞进 SecurityContextHolder后续授权就拿着它来判断“你是谁、你能干什么”。理解这条链路后至少在排查三类问题时会非常舒服如果你实现了 UserDetailsService 但没生效检查是否被 Spring 容器扫描到以及提供的 Bean 类型是否被正确注入。如果密码一直匹配失败多半是 PasswordEncoder 类型对不上比如注册时用了 BCrypt校验时却因为配置缺失导致系统不知道用哪种编码器。如果你自定义了 AuthenticationProvider但没有通过 AuthenticationManager 接入配置再漂亮也白搭。3. 实操从零搭建 Spring Boot 3 Spring Security 项目不跑起来光看文档等于没学。这一节我带大家走一遍完整的最小实操流程包含一个真实可跑的 Spring Boot 3 项目以及配置里每一步为什么这样写。3.1 创建项目与依赖版本我使用的是 Spring Initializr 生成的 Maven 项目关键信息如下JDK 17Spring Boot 3 最低要求是 17Spring Boot 版本选 3.2.5对应 Spring Security 6.2.x依赖只添加了 Spring Web、Spring Security、Thymeleaf为了自定义登录页pom.xml 里 Spring Security 的依赖坐标是 spring-boot-starter-security由 Spring Boot 父工程统一管理版本不需要手动指定。启动项目后浏览器访问任意接口你会发现页面自动跳到一个默认登录页用户名是 user密码是启动日志里随机生成的那串 UUID。这说明默认过滤器链已经生效你还没写任何配置类。这一步我特别强调是因为很多初学者会忘了创建配置类然后求助为什么没有默认登录页。如果默认登录页都没出现先检查依赖是否引入再检查启动类是否在根包路径让组件能被扫描到。3.2 最小 SecurityFilterChain 配置我新建一个 SecurityConfig 类package com.example.demo.config; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.security.config.annotation.web.builders.HttpSecurity; import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity; import org.springframework.security.web.SecurityFilterChain; Configuration EnableWebSecurity public class SecurityConfig { Bean public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception { http .authorizeHttpRequests(auth - auth .requestMatchers(/, /home, /login, /css/**).permitAll() .requestMatchers(/admin/**).hasRole(ADMIN) .anyRequest().authenticated() ) .formLogin(form - form .loginPage(/login) .permitAll() ) .logout(logout - logout .logoutUrl(/logout) .logoutSuccessUrl(/home) ); return http.build(); } }注意几个细节。EnableWebSecurity 在 Spring Boot 应用中加上会更明确其实 Spring Boot 自动配置已经会开启它但写出来可以让阅读代码的人一眼知道这是安全配置。requestMatchers(/, /home, /login, /css/**).permitAll() 是让这些路径不需要登录就能访问因为如果你的登录页本身都被保护那就永远无法进入登录流程了。anyRequest().authenticated() 作为兜底规则保证其他请求都需要认证。3.3 内存用户与 PasswordEncoder上面的配置如果现在跑登录框都看不到自定义页面更没法登录因为还没有用户数据源。我先用最简单的内存用户演示package com.example.demo.config; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.security.core.userdetails.User; import org.springframework.security.core.userdetails.UserDetails; import org.springframework.security.core.userdetails.UserDetailsService; import org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder; import org.springframework.security.crypto.password.PasswordEncoder; import org.springframework.security.provisioning.InMemoryUserDetailsManager; Configuration public class UserConfig { Bean public UserDetailsService userDetailsService(PasswordEncoder passwordEncoder) { UserDetails user User.builder() .username(user) .password(passwordEncoder.encode(123456)) .roles(USER) .build(); UserDetails admin User.builder() .username(admin) .password(passwordEncoder.encode(admin123)) .roles(ADMIN) .build(); return new InMemoryUserDetailsManager(user, admin); } Bean public PasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(); } }在大约 Spring Security 5.7 之后我几乎没再看到官方推荐使用 InMemoryUserDetailsManager 做生产环境用户源但用于本地实验和学习非常合适。这里有两处容易犯错的地方第一User.builder() 里的 password 必须是已编码的密文不能直接存明文所以必须注入 PasswordEncoder 并调用 encode第二roles(ADMIN) 会让该用户自动拥有 ROLE_ADMIN 这个权限标识后面在授权配置里用 hasRole(ADMIN) 就能对应上。如果你非得用明文密码做实验可以配置一个 DelegatingPasswordEncoder然后故意写成 {noop}123456也就是密码存成前缀 明文的形式。但这种写法只是为了兼容历史系统千万别在生产环境里这样干。3.4 自定义登录页与 CSRF 处理从默认登录页过渡到自定义登录页是很多人迁移到 Spring Boot 3 后的第一个硬需求。表单登录配置里指定 loginPage(/login) 后如果你的应用没有任何路径为 /login 的 ControllerSpring Security 会提供一个默认的登录页。我们这里用 Thymeleaf 写一个最简单的 login.html!DOCTYPE html html xmlns:thhttp://www.thymeleaf.org head meta charsetUTF-8 title登录/title /head body form th:action{/login} methodpost div label用户名/label input typetext nameusername /div div label密码/label input typepassword namepassword /div button typesubmit登录/button /form /body /html表单里的用户名和密码字段名必须叫 username 和 password因为 UsernamePasswordAuthenticationFilter 默认按这两个参数名解析。如果想自定义参数名可以让配置支持 authenticationDetailsSource 之类的扩展但没必要。这里最值得提醒的是 CSRF。Spring Security 6 默认启用 CSRF 保护所有 POST、PUT、DELETE 请求都会校验 CSRF Token。表单提交时Thymeleaf 模板引擎会自动帮你在表单里注入隐含的_token字段吗不一定。上面那个纯手写 HTML 没有带 token毫不意外会收到 403。常见的两种解决方案在 Thymeleaf 表单里加一个隐藏域使用官方提供的 th:action 时Thymeleaf 并不会自动注入 CSRF token因为这是 Spring Security 与 Spring MVC 集成时通过 RequestDataValueProcessor 实现的。实际测试时如果你引入的是 Thymeleaf 的 Spring Security 方言可以使用 th:action{/login}并且页面里声明 xmlns:sec 相关命名空间时框架往往会自动补上 CSRF 隐藏域。如果是前后端分离的 JSON 请求建议在开发初期暂时关闭 CSRF 保护登录成功后使用 JWT 之类的 Token 做后续身份校验。生产环境中是否需要 CSRF取决于你的认证方式如果不用 Cookie 做会话那么 CSRF 风险会低很多但也不是完全没有需要单独评估。我在本地实验时为了快速跑通流程第一种方案配合 Thymeleaf 方言最简单。3.5 启动测试与请求观察配置完成后启动项目访问 http://localhost:8080/home如果配置正确应该能直接看到首页内容而访问任意未放行接口会被重定向到登录页。输入内存用户的账号密码登录成功后浏览器会生成 JSESSIONID Cookie。再用开发者工具看请求你会观察到登录成功后响应头里有 Set-Cookie 和类似的会话标志。这个观察很重要因为它能帮助你区分“认证”和“授权”的边界认证是拿 Cookie 或 Token 换身份授权是拿身份换资源访问权。Spring Security 把这两条逻辑都塞在过滤器链里所以如果你看到请求被 302 到 /login说明请求还没认证看到 403说明你已经认证但角色权限不够看到 200说明这一关顺利通过。4. 从 Spring Boot 2 迁移到 3 时最常踩的坑这一节专门讲迁移。我见过很多项目从 Spring Boot 2.7 升到 3.2安全配置完全重写后依然会碰到各种摸不着头脑的问题。这里挑四个高频坑每一个都对应真实报错或现象。4.1 老是 403但不知道是 CSRF 还是权限不够这是迁移后最容易混淆的问题。403 可以由很多过滤器产生最常见的就是 CSRF 过滤器先于认证过滤器判断请求。如果是 CSRF 拒绝请求往往在还没进入登录流程之前就被挡下响应体里通常带着 Invalid CSRF Token 或者 Could not verify the provided CSRF token。如果是权限不足那你已经登录成功只是当前用户角色不允许访问目标资源Spring Security 默认会抛出 AccessDeniedException。排查技巧很简单先看浏览器控制台请求是 POST 还是 GET。如果是 POST先想起 CSRF如果请求里没有任何 CSRF Token基本就是它了。如果你暂时不打算让前后端分离架构处理 CSRF可以直接在配置里写 http.csrf(csrf - csrf.disable())但必须清楚这只是开发阶段省事不是无脑推荐的做法。4.2 依赖还是 javax.*编译直接失败Spring Boot 3 的一大技术变更是把 Jakarta EE 9 作为基础Spring Security 内部的 Servlet 相关 API 也从 javax.servlet 迁移到 jakarta.servlet。如果你从旧项目拷贝代码可能会看到一系列 import javax.servlet.* 报红这跟 Spring Security 没直接关系但会一并爆发。解决办法是全局替换所有 javax.servlet 改成 jakarta.servlet如果项目里还依赖了一些第三方库一定要确认它们有适配 Jakarta 的版本。举个例子如果你的项目使用了旧版的 一个 工具包且它内部强依赖 javax.servlet API升级 Spring Boot 3 后会直接冲突。最稳妥的做法是只保留 Spring Boot 3 对应版本体系的第三方库遇到不兼容库要么找新版本要么换实现。4.3 密码总是匹配失败明明数据库里存的是加密串一个很有意思的场景是从 Spring Boot 2 旧项目迁移过来数据库里的密码是旧代码用 Md5PasswordEncoder 之类的东西生成的。到了 Spring Security 6 之后官方把很多被判定为不安全的密码算法标注为弱算法默认不再支持。你只是在配置里写了一个 BCryptPasswordEncoder但数据库里老用户的密码根本就不是 BCrypt 格式匹配自然失败。这时候如果你把 PasswordEncoder 换成 DelegatingPasswordEncoder并给旧密码加上对应的算法前缀例如 {MD5}xxx就能兼容历史数据。但这只是一条过渡路线长期方案还是要说服业务方把密码统一升级到 BCrypt 或更安全的算法。这个坑在官网的 Password Storage 章节里有明确说明所以我一直建议迁移前先读一遍官方文档别等线上报错才回头翻。4.4 多个 SecurityFilterChain Bean 的顺序和覆盖问题Spring Security 6 也支持定义多个 SecurityFilterChain Bean实现类似“后台接口走严格安全规则、前端静态资源走宽松规则”的效果。但多个过滤器链一起出现时顺序极其关键。Spring Security 会按声明顺序从上往下匹配请求第一个匹配到的 SecurityFilterChain 生效。如果你把宽松配置放在前面严格的配置放在后面敏感接口全部被宽匹配抢走后面的规则永远没有执行机会。实际表现就是明明给 /api/** 配置了受了角色限制但请求依然能通过因为前面的 SecurityFilterChain 已经用 permitAll 把请求放行了。解决办法是在多个 Bean 上显式标注 Order(1)、Order(2) 等把最严格的规则放到最小序号最宽松的放到最后或者干脆不要用多个过滤器链集中到一个配置里按 requestMatchers 做细分。另外注意一个细节每个 SecurityFilterChain 的 HttpSecurity 配置需要独立的实例如果从一个 Bean 方法里返回同一个 http 对象两次Spring 会报出 “A filter chain already exists” 之类的错误。老老实实声明多个方法各自接收 HttpSecurity 注入。5. 常见问题速查表与排查思路现象可能原因排查方法 / 解决启动后所有接口直接返回 401 / 403登录页不出现依赖已引入但没有配置 permitAll或者 Spring Security 认证方式默认对路径全部拦截配置 authorizeHttpRequests将静态资源、登录页放行表单 POST 登录返回 403页面没有 _token 字段CSRF 校验未通过引入 Thymeleaf Spring Security 方言或暂时 http.csrf(csrf - csrf.disable())登录成功但访问 /admin 接口 403用户角色不对或授权表达式写错检查 UserDetails 的 granted authorities确认 hasRole / hasAuthority 是否匹配密码一直匹配失败注册时和校验时使用不同 PasswordEncoder或数据库中密码格式带未知前缀统一配置固定 PasswordEncoder Bean检查密码字段是否被自动加前缀编译报错 antMatchers / authorizeRequests 方法不存在依赖版本为 6.x旧 API 被移除全部替换为 requestMatchers / authorizeHttpRequests并检查 import 路径自定义登录页跳转后 CSS 加载 404 / 403静态资源未放行在 requestMatchers 里加上 /css/, /js/, /images/** 等路径配置类写了 EnableWebSecurity 却完全没生效启动类扫描包路径不对或依赖缺失确认启动类能扫描到配置类检查 pom.xml 中是否包含 spring-boot-starter-security多个 SecurityFilterChain 下接口能匿名访问宽松配置匹配顺序太靠前使用 Order 严格控制顺序优先声明严格规则登录成功后页面无法跳转回原页面表单登录默认成功策略是跳到上一次请求页面但并发或跨域场景下丢失配置 successHandler 或 defaultSuccessUrl排查思路的核心是“分层看”先看请求有没有到过滤器链再看是认证失败还是授权失败最后看是代码问题还是配置问题。Spring Security 的过滤器链调试起来比普通方法调用麻烦因为异常类型和响应状态码有时不会给出明确堆栈。我常用的手法是在 Filter 层临时打印日志或者在不影响安全的前提下把日志级别调到 DEBUG观察 UsernamePasswordAuthenticationFilter 和 AuthorizationFilter 的每一步结果比凭空猜快得多。6. 2024 年学习 Spring Security 的推荐路径这一节不是官方文档的搬运只是我自己走过一遍后的路线图。官网文档是参考书但你不能一上来抱着手册读要有任务驱动。6.1 先把默认行为摸到一清二楚第一周不需要写任何安全配置只引入依赖启动一个最简单的 Web 应用然后观察 Spring Security 是怎么拦截所有请求的。先用浏览器访问记下默认登录页长什么样再用 curl 发几个不带头部信息的请求看看 401 和 302 的具体表现。这个过程能帮你建立最基本的安全直觉。很多人跳过这一层直接看配置代码导致后续遇到“为什么没有重定向到登录页”这种最基础的问题时毫无头绪。另外用 IntelliJ IDEA 或 Eclipse 把 Spring Security 的 jar 包源码挂上点进 SecurityFilterChain、FilterChainProxy、UsernamePasswordAuthenticationFilter 的源码看看。不一定每行都懂但至少知道过滤器链为什么是一个链异常是在哪个位置被捕获并转成响应状态的。6.2 第二个任务做一个自定义表单登录在理解默认行为后开始做自定义表单登录。这一个小任务就会把你拉进 CSRF、UserDetailsService、PasswordEncoder、Session 这几个核心主题。我的建议是可以专门写一个测试工程只做登录和注销不做其他业务接口把各种配置组合都试一遍。尝试把登录页改成 GET /login 和 POST /login 两个分支你就能理解为什么表单登录要 permitAll而 POST 又要同时满足 CSRF 校验。这个过程里我强烈建议你打印一下 SecurityContextHolder.getContext().getAuthentication()观察一个请求从匿名状态到认证成功后的 Authentication 对象内容。这个对象里有 principal、credentials、authorities 三部分理解了它就理解了大多数认证模型。6.3 第三个任务切换到数据库用户内存用户会给你对称的甜头但它隐藏了很多细节。真正做项目时一般会从数据库读取用户再做角色权限分配。你需要实现一个 UserDetailsService 的实现类从数据库查询用户并组装成 UserDetails 对象。一个 UserDetails 的映射逻辑如果数据库字段和默认字段不一致怎么适配。权限数据从数据库表里拿还是现算以及角色层级结构怎么设计。这一步如果衔接不好最常见的错误是把 UserDetails 和实体类混在一起导致缓存、序列化、懒加载一堆问题。官网推荐的思路是定义一个独立的 UserDetails 对象与数据库实体分开业务层负责转换。我当时按照官方文档的 “JdbcUserDetailsManager” 和自定义 UserDetailsService 两种方式各写了一遍才真正明白 UserDetails 只是一个适配层并不需要和数据库表结构一一对应。6.4 第四个任务方法安全与接口细粒度控制等表单登录和数据库用户都跑通后你可以开始研究 PreAuthorize 这类方法安全注解。方法安全是 Spring Security 授权的延伸它不是在过滤器链层拦截而是在进入 Service/Controller 方法前通过 AOP 机制拦截并做权限判断。常见的写法PreAuthorize(hasRole(ADMIN)) public void deleteUser(Long id) { ... }使用前需要在配置类上开启 EnableMethodSecuritySpring Security 6 中这个注解替代了旧版的 EnableGlobalMethodSecurity。如果你的类路径下没有 AOP 依赖方法安全也是能工作的吗实际上 EnableMethodSecurity 会自动引入必要的代理机制但如果项目里已经用了其他 AOP 配置偶尔会受到影响这时需要检查代理模式是 JDK 动态代理还是 CGLIB。6.5 最后一步按需阅读官方高级章节当你把认证、授权、自定义登录、数据库用户都手写过一遍再回来看官网的 OAuth2、JWT、方法安全、Remember Me、Session 管理这些高级章节就会觉得清晰很多。我个人到最后反而回头看文档次数最多的地方是 CSRF 的若干边界情况、方法安全的 SpEL 表达式以及多过滤器链的匹配细节。这些东西不写到项目中永远记不牢。7. 学习材料的取舍和自己动手的心得最后想分享一点个人体会。Spring Security 的官网文档不是那种“读完就懂一切”的文档它更像是 API 参考加架构说明书的混合体。真正让它对你产生价值的是你带着明确问题去翻阅然后在本地实验里反复验证。我建议每个想学好 Spring Security 的开发者准备一个专门的沙盒项目故意写错误配置观察控制台输出和浏览器表现。比如故意把 CSRF 关掉然后去看登录是否正常再把 CSRF 打开并模拟缺失 token 的请求你亲手制造一次 403再去官网查为什么会这样。这个过程比刷十篇教程都有用。另外一个小技巧在测试代码里尽量多用 SecurityContextHolder.getContext().getAuthentication() 去打印当前认证状态如果你能随时说出“当前这行代码执行时SecurityContext 里有什么”你对 Spring Security 的掌握就远超大多数人。不要着急抄配置先把过滤器链的运行逻辑装进脑子里。后面无论版本怎么迁移你都能快速定位到对应章节和 API而不是靠记忆硬背一堆配置代码。
