1. 项目概述与整体设计思路1.1 为什么要花大力气搞 Spring Security刚接手某个模拟项目X的时候我其实挺纠结的项目里已经有了一套基于拦截器和 ThreadLocal 的简易登录体系能跑、能用看起来也没啥大毛病。但后来随着接口越来越多、角色权限开始分化问题就冒出来了——每个新接口都要手动写权限判断改一个角色的权限要翻好几个类而且 Session 在前后端分离的架构下越来越别扭。折腾到第三次因为忘了加拦截规则导致越权访问之后我决定把这块彻底重写。选型的时候其实也没太多犹豫。市面上主流的方案无非是 Spring Security 和 Apache ShiroSpring Security 虽然上手门槛高但它和 SpringBoot 的整合是亲儿子级别的资源隔离、过滤器链、SPEL 表达式这些底层能力非常完整更重要的是它不止能解决“登录”这么简单的问题后续做 OAuth2、OIDC 甚至方法级权限控制都能平滑接上。如果只是短期救火Shiro 确实更简单但考虑到项目后面还要接第三方登录和细粒度权限我最终选了 Spring Security这个决定在后来的开发过程中被证明是正确的。这篇教程不是那种“照着敲一遍能跑就行”的Demo而是把你真正会遇到的场景走一遍SpringBoot 怎么接入、前后端分离怎么做认证、JWT 怎么用、权限怎么配、跨域怎么处理、遇到坑怎么排查。整个过程基于我实际动手改造一个项目的经验所有代码都经过验证你可以直接参考来做自己的方案。1.2 前后端分离下的认证方案选型传统单体应用用 Session 很自然登录成功往服务端存 Session浏览器自动带 Cookie什么都不用管。但前后端分离之后你的前端可能跑在另一个端口甚至另一台服务器上而且现在主流前端都是 Node 环境启动Cookie 的跨域携带和 CSRF 防护就成了老大难问题。我采用的方案是无状态 JWT登录成功后服务端签发一个 token 返回给前端前端存起来一般放 localStorage 或者内存里后续每个请求在 Header 里带上Authorization: Bearer token。服务端不保存会话状态只需要通过签名验证 token 的合法性就能识别用户身份和权限。这么做的好处很直接天然支持跨域不依赖 Cookie服务端无状态方便水平扩展前端对接简单逻辑清晰当然JWT 也有它的问题最常被诟病的是无法主动吊销。但在内部项目、中小型系统的场景下这个问题可以通过短有效期加刷新令牌的方式缓解完全在可接受范围内。2. Spring Security 核心原理解读2.1 过滤器链机制一切安全控制的骨架Spring Security 的底层是一组有序的过滤器它们像流水线一样依次处理每个 HTTP 请求。这个设计可能看起来复杂但一旦理解了你就能精准定位问题、自定义扩展。关键过滤器大概有这几个SecurityContextPersistenceFilter从请求中恢复或创建安全上下文UsernamePasswordAuthenticationFilter处理表单登录请求BasicAuthenticationFilter处理 HTTP Basic 认证ExceptionTranslationFilter捕获认证、授权异常并转换成对应的 HTTP 响应FilterSecurityInterceptor做最终的授权判断每个过滤器只做一件事然后通过FilterChain把请求传递给下一个。这个设计有点像工厂流水线——每个工位完成自己的工序最后出来的是合格的“产品”。理解了过滤器链的机制你就明白为什么 Spring Security 会有那么多“自定义 Filter”的配置项。比如我们下面要做的 JWT 认证本质上就是在用户名密码认证这个环节加一个自己的过滤器来替换掉默认行为。2.2 认证流程一次完整请求的旅程当后端收到一个需要认证的请求时整个流程是这样的请求进入过滤器链首先经过SecurityContextPersistenceFilter如果配置了 JWT 过滤器它从请求头里取出 token交给JwtAuthenticationProvider校验如果 token 合法构建一个UsernamePasswordAuthenticationToken放入SecurityContext标记为已认证请求继续往下走来到FilterSecurityInterceptor拦截器根据配置的规则比如hasRole(ADMIN)比对当前用户拥有的权限如果权限足够请求放行到 Controller否则抛出异常由ExceptionTranslationFilter处理返回 403整个过程环环相扣。最关键的哲学是认证决定你是谁授权决定你能干什么。前者在过滤器的前段完成后者在后段完成。这个区分非常重要排查问题的时候先判断是哪一环出了问题能省很多时间。2.3 授权模型基于 RBAC 的角色权限设计Spring Security 的授权建立在“权限”这个概念上。说得直白点它把权限看成一组字符串集合角色本质上也是一种特殊的权限字符串比如ROLE_ADMIN。实际做项目的时候我习惯把权限设计成三层资源层对应每一个后端接口定义需要的权限标识角色层把一组权限打包成一个角色用户层给用户分配角色比如某个管理接口需要system:user:list这个权限我可以创建一个管理员角色里面包含这个权限然后把角色分配给某个用户。Spring Security 里做这种控制有几种方式URL 规则在SecurityFilterChain配置里用requestMatchers().hasAnyAuthority()控制方法注解在 Controller 或 Service 方法上使用PreAuthorize(hasAuthority(system:user:list))动态权限实现在FilterInvocationSecurityMetadataSource中根据请求动态查找所需权限日常项目我用第一种配合第二种组合既能保证入口可控又能在业务方法层面做细粒度校验。3. 实操SpringBoot 集成 Spring Security 完整步骤3.1 环境准备与依赖引入我用的环境是 SpringBoot 2.7.x 加 Spring Security 5.7.xJDK 1.8。选这个组合不是因为版本新而是因为它足够稳定网上能查到的资料也最多。如果你用的是 SpringBoot 3.x底层是 Jakarta EE一些类名会变化配置思路完全一致就是注意别混淆。首先引入核心依赖dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-security/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-api/artifactId version0.11.5/version /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-impl/artifactId version0.11.5/version scoperuntime/scope /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-jackson/artifactId version0.11.5/version scoperuntime/scope /dependency引入spring-boot-starter-security之后SpringBoot 会提供一套默认的登录页和密码。如果你什么都不配就启动项目访问任何接口都会跳到默认登录页。所以下一步就是写一个配置类覆盖默认行为。注意默认情况下 Spring Security 会拦截所有请求第一次引入依赖后启动项目你会看到控制台打印一串随机的 UUID 密码账号是user。记得先确认依赖生效再去改写配置避免一步到位时出了问题不好定位。3.2 数据模型与 UserDetailsServiceSpring Security 需要一个东西告诉它“用户的密码是什么、有哪些权限”。这个接口就是UserDetailsService。写一个实现类从数据库查出用户信息然后封装成框架能理解的UserDetails对象。我这里的示例用 MyBatis-Plus 做持久层核心代码如下Service public class UserDetailsServiceImpl implements UserDetailsService { Resource private SysUserMapper sysUserMapper; Resource private SysRoleMapper sysRoleMapper; Override public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException { SysUser user sysUserMapper.selectOne( new LambdaQueryWrapperSysUser().eq(SysUser::getUsername, username)); if (user null) { throw new UsernameNotFoundException(用户不存在); } // 查询用户的角色编码集合例如 ROLE_ADMIN ListString roles sysRoleMapper.selectRoleCodesByUserId(user.getId()); // 这里的 authorities 既可以是角色也可以是权限字符串 ListSimpleGrantedAuthority authorities roles.stream() .map(SimpleGrantedAuthority::new) .collect(Collectors.toList()); return new org.springframework.security.core.userdetails.User( user.getUsername(), user.getPassword(), user.getStatus() 1, true, true, true, authorities); } }这里有个小细节SimpleGrantedAuthority接受的字符串如果是角色的话要带ROLE_前缀否则你用hasRole(ADMIN)匹配不上。如果你用hasAuthority(ADMIN)就不用带。两种写法等价但混用会让人头大我习惯统一用ROLE_前缀 hasRole。数据库密码必须是 BCrypt 加密过的。你可以在登录注册接口里用BCryptPasswordEncoder对明文密码做加密存储然后在 Spring Security 配置里也声明一个BCryptPasswordEncoderBean。框架会自动用 BCrypt 的matches方法校验。3.3 JWT 工具类与认证过滤器这是前后端分离方案的核心环节。我写一个工具类负责 token 的创建和解析使用 jjwt 库完成。Component public class JwtTokenUtil { Value(${jwt.secret}) private String secret; Value(${jwt.expiration}) private Long expiration; private SecretKey getSigningKey() { byte[] keyBytes Decoders.BASE64.decode(secret); return Keys.hmacShaKeyFor(keyBytes); } public String generateToken(String username, ListString roles) { Date now new Date(); Date expireDate new Date(now.getTime() expiration * 1000); return Jwts.builder() .setSubject(username) .claim(roles, roles) .setIssuedAt(now) .setExpiration(expireDate) .signWith(getSigningKey(), SignatureAlgorithm.HS512) .compact(); } public Claims parseToken(String token) { return Jwts.parserBuilder() .setSigningKey(getSigningKey()) .build() .parseClaimsJws(token) .getBody(); } }然后写一个过滤器继承OncePerRequestFilter保证一次请求只过滤一次Component public class JwtAuthenticationFilter extends OncePerRequestFilter { Resource private JwtTokenUtil jwtTokenUtil; Resource private UserDetailsServiceImpl userDetailsService; Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException { String authHeader request.getHeader(Authorization); if (authHeader ! null authHeader.startsWith(Bearer )) { String token authHeader.substring(7); try { Claims claims jwtTokenUtil.parseToken(token); String username claims.getSubject(); if (username ! null SecurityContextHolder.getContext().getAuthentication() null) { UserDetails userDetails userDetailsService.loadUserByUsername(username); UsernamePasswordAuthenticationToken authentication new UsernamePasswordAuthenticationToken( userDetails, null, userDetails.getAuthorities()); authentication.setDetails(new WebAuthenticationDetailsSource().buildDetails(request)); SecurityContextHolder.getContext().setAuthentication(authentication); } } catch (Exception e) { // token 无效或过期不设置认证信息后续过滤器自然拦截 logger.warn(JWT authentication failed: {}, e.getMessage()); } } filterChain.doFilter(request, response); } }这段代码的要点是过滤器只负责解析和设置认证信息不做拦截判断。如果 token 无效就什么都不做让请求继续往后走最后由ExceptionTranslationFilter或授权过滤器统一处理。这样职责单一出问题也好排查。3.4 核心 Security 配置类这是整个项目里最关键的一个类。我基于 Spring Security 5.7 的新写法用SecurityFilterChainBean 配置从前不再继承WebSecurityConfigurerAdapter。Configuration EnableWebSecurity EnableGlobalMethodSecurity(prePostEnabled true) public class SecurityConfig { Resource private JwtAuthenticationFilter jwtAuthenticationFilter; Resource private RestAuthenticationEntryPoint authenticationEntryPoint; Resource private RestAccessDeniedHandler accessDeniedHandler; Bean public PasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(); } Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http.csrf().disable() .cors().and() .sessionManagement() .sessionCreationPolicy(SessionCreationPolicy.STATELESS) .and() .authorizeHttpRequests() .requestMatchers(/api/auth/login).permitAll() .requestMatchers(/api/auth/register).permitAll() .requestMatchers(/api/public/**).permitAll() .anyRequest().authenticated() .and() .exceptionHandling() .authenticationEntryPoint(authenticationEntryPoint) .accessDeniedHandler(accessDeniedHandler) .and() .addFilterBefore(jwtAuthenticationFilter, UsernamePasswordAuthenticationFilter.class); return http.build(); } }逐个解释一下这些配置的作用csrf().disable()前后端分离 JWT 无状态方案下CSRF 防护意义不大而且开了之后遇到跨域 POST 请求很容易被拦。我直接关掉。cors()开启跨域支持配合后面要加的CorsConfigurationSourceBean 使用。sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)告诉框架不要在服务端创建 Session这是无状态方案的关键。authorizeHttpRequests()定义 URL 访问规则放行登录、注册和静态资源其余都要认证。exceptionHandling()指定认证失败401和权限不足403时返回的 JSON 结构。addFilterBefore(jwtAuthenticationFilter, UsernamePasswordAuthenticationFilter.class)把自己的过滤器加到认证过滤器之前。3.5 认证成功与失败的返回结构前后端分离的项目里后端要返回的是 JSON不是跳转页面。所以需要自定义两个处理器Component public class RestAuthenticationEntryPoint implements AuthenticationEntryPoint { Override public void commence(HttpServletRequest request, HttpServletResponse response, AuthenticationException authException) throws IOException { response.setStatus(HttpServletResponse.SC_UNAUTHORIZED); response.setContentType(application/json;charsetUTF-8); response.getWriter().write(JSON.toJSONString( R.fail(401, 未登录或登录已过期))); } }AuthenticationEntryPoint处理的是未认证的请求也就是匿名用户访问受保护资源时。返回 401。Component public class RestAccessDeniedHandler implements AccessDeniedHandler { Override public void handle(HttpServletRequest request, HttpServletResponse response, AccessDeniedException accessDeniedException) throws IOException { response.setStatus(HttpServletResponse.SC_FORBIDDEN); response.setContentType(application/json;charsetUTF-8); response.getWriter().write(JSON.toJSONString( R.fail(403, 没有访问权限))); } }AccessDeniedHandler处理的是已登录但没有权限的请求返回 403。这两个类看着简单但特别容易被漏掉。不写它们的话前后端分离项目里遇到未登录的场景前端收到的可能是一段 HTML 错误页JSON 解析直接报错排查半天才发现是这里的问题。3.6 登录接口的实现有了框架的基础配置登录接口就变得非常简洁了。核心逻辑是校验用户名密码生成 token 返回给前端。RestController RequestMapping(/api/auth) public class AuthController { Resource private AuthenticationManager authenticationManager; Resource private JwtTokenUtil jwtTokenUtil; Resource private UserDetailsServiceImpl userDetailsService; PostMapping(/login) public R login(RequestBody LoginRequest loginRequest) { Authentication authentication; try { authentication authenticationManager.authenticate( new UsernamePasswordAuthenticationToken( loginRequest.getUsername(), loginRequest.getPassword())); } catch (BadCredentialsException e) { return R.fail(400, 用户名或密码错误); } SecurityContextHolder.getContext().setAuthentication(authentication); UserDetails userDetails userDetailsService.loadUserByUsername(loginRequest.getUsername()); ListString roles userDetails.getAuthorities().stream() .map(GrantedAuthority::getAuthority) .collect(Collectors.toList()); String token jwtTokenUtil.generateToken(userDetails.getUsername(), roles); return R.ok(登录成功, token); } }注意这里需要把AuthenticationManager暴露成 Bean否则Resource注入不进来。可以在配置类里加Bean public AuthenticationManager authenticationManager( AuthenticationConfiguration configuration) throws Exception { return configuration.getAuthenticationManager(); }4. 前后端分离场景下的关键配置4.1 跨域处理前后端分离绕不开 CORS。最常见的场景是前端跑在http://localhost:5173后端跑在http://localhost:8080端口不同就触发了跨域限制。在 Spring Security 里开启跨域需要定义一个CorsConfigurationSourceBeanBean public CorsConfigurationSource corsConfigurationSource() { CorsConfiguration configuration new CorsConfiguration(); configuration.setAllowedOriginPatterns(Arrays.asList(http://localhost:*, http://127.0.0.1:*)); configuration.setAllowedMethods(Arrays.asList(GET, POST, PUT, DELETE, OPTIONS)); configuration.setAllowedHeaders(Arrays.asList(*)); configuration.setAllowCredentials(true); configuration.setMaxAge(3600L); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, configuration); return source; }注意浏览器在跨域请求前会先发一个 OPTIONS 预检请求。配置里放行了 OPTIONS 方法同时.authorizeHttpRequests()里也确实执行到了。我在实际项目中遇到过一种情况预检请求没有带 Authorization 头但被anyRequest().authenticated()拦住了导致前端跨域请求永远失败报 401 而不是真正的原因。这种情况需要在配置里放行 OPTIONS 请求.requestMatchers(HttpMethod.OPTIONS, /**).permitAll()4.2 无状态会话的细节把SessionCreationPolicy设置为STATELESS之后Spring Security 不会再创建HttpSession每个请求都是独立处理的。这带来一个隐含问题你不能再依赖SecurityContextHolder跨请求保留数据。有同事问过我登录接口里明明把认证信息放进了SecurityContextHolder为什么下一个请求读取不到因为无状态模式下SecurityContextPersistenceFilter不会把SecurityContext存到 Session每个请求进来都是全新的。用户身份全靠 JWT 过滤器重新构建这恰恰是无状态设计的核心思想。另外要注意线程池场景SecurityContextHolder默认使用ThreadLocal存储如果你在异步任务里读取用户信息需要手动传递SecurityContext。可以使用DelegatingSecurityContextRunnable包装异步任务或者干脆在异步任务入口通过参数传递用户 ID我更推荐后者显式传参比隐式上下文更可靠。4.3 统一响应结构的实践前后端分离项目里接口返回值最好统一包装。我这里用了一个极简的R类public class R { private int code; private String message; private Object data; public static R ok(String message, Object data) { return new R(200, message, data); } public static R fail(int code, String message) { return new R(code, message, null); } }统一响应结构很重要的原因是前端拦截器只需要在一处处理code ! 200的情况比如跳到登录页、弹出错误提示不用每个接口单独判断。尤其是 401 和 403 的场景前后端约定好code的含义对接效率会高很多。5. 常见问题与排查实录5.1 常见问题速查表我把实际开发中遇到的高频问题整理成一张表方便你按图索骥现象可能原因排查思路登录成功后一切正常但过一会儿接口开始 401token 过期检查expiration配置前端需要在 401 时自动刷新 token 或重新登录所有请求都返回 403权限配置不正确检查角色前缀是否带ROLE_检查PreAuthorize表达式Swagger/静态资源被拦截静态资源路径未放行在authorizeHttpRequests中放行/swagger-ui/**,/v3/api-docs/**等路径前端提交登录请求就报 405可能被 CSRF 拦截确认csrf().disable()已配置跨域 POST 请求成功但 GET 请求失败预检请求被拦截放行 OPTIONS 请求检查 CORS 配置JWT 解析报SignatureException签名密钥不匹配检查前后端密钥是否一致如果密钥太短也会报错HS512 至少需要 64 字节用户明明有角色但hasRole(ADMIN)返回 false权限字符串没有前缀确保SimpleGrantedAuthority传入的是ROLE_ADMIN自定义过滤器不生效过滤器顺序错误确认addFilterBefore的位置且 Bean 已注册到容器控制台打印随机密码还没有自定义UserDetailsService配置一个UserDetailsServiceBean 即可覆盖默认逻辑5.2 我踩过的几个深坑第一个坑是 Spring Security 的默认登录页。引入依赖之后做前后端分离改造我没有第一时间改配置结果启动后访问接口弹出了默认登录页我还以为是前端路由配置错了。这个坑其实不难就是提醒大家引入依赖后先确认默认行为再动手改造。第二个坑是关于UserDetailsService的返回类型。我用的是自己定义的用户实体类直接返回了那个实体对象框架报ClassCastException。查了半天才发现UserDetailsService必须返回UserDetails类型不能用别的替代。后来我干脆直接用框架自带的org.springframework.security.core.userdetails.User包装一层省事且稳。第三个坑是 JWT 密钥长度。我一开始随便写了个短字符串当密钥HS512 算法要求至少 64 字节启动没报错但一解析就报WeakKeyException。这种异常比较隐蔽因为它出现在访问接口的时候而不是启动的时候。我的做法是把 secret 配置成 Base64 编码的长字符串然后在代码里解码一劳永逸。第四个坑比较隐蔽多个SecurityFilterChain的顺序问题。如果你的项目既有接口又有管理系统页面你可能会定义多个过滤链。Spring Security 按Order决定匹配顺序必须把精确匹配的放前面通用的/ **放最后。我就犯过一次把通用链放前面的错误导致自定义的 JWT 规则直接没走到。5.3 排查工具和调试技巧排查 Spring Security 问题时我通常的做法先把日志级别调整到 DEBUG特别是org.springframework.security这个包。在application.yml里设置logging: level: org.springframework.security: DEBUG开启 DEBUG 日志后过滤器链的执行过程会打印出来你能清楚看到哪些过滤器处理了请求、认证信息是什么、为什么被拒绝。这对新手来说比盲目改配置高效得多。另外如果用的是 IDEA自带的 HTTP Client 比 Postman 更适合调试因为可以保存请求历史方便复现问题。调试 JWT 接口时注意看请求头里Authorization是否带上了Bearer前缀——前端漏掉这个前缀是我印象中出现频率最高的对接问题。6. 权限控制的进阶玩法6.1 方法级权限注解URL 级别的拦截只能控制到“这个接口谁能访问”但实际业务里经常有更细的要求同一个接口不同角色看到的数据不同或者对某个操作有额外限制。这时候就用方法级注解。在配置类里加了EnableGlobalMethodSecurity(prePostEnabled true)之后就可以在方法上写注解了PreAuthorize(hasRole(ADMIN)) public void deleteUser(Long userId) { // 只有管理员可以调用 }PreAuthorize(hasAuthority(system:user:update)) public void updateUser(SysUser user) { // 拥有特定权限才能调用 }方法级注解比 URL 规则灵活得多可以在业务层做精细化控制。但要注意性能库里不要滥用每一个PreAuthorize评估都是运行时开销而且一旦散落在各个方法里权限规则的可视性会变差。我习惯的做法是URL 规则管大方向放行、认证方法注解管细节角色、权限两层配合使用。6.2 动态权限数据源如果你觉得角色和权限是写死在代码里的不够灵活可以考虑做动态权限。思路是把“哪个 URL 需要哪个权限”的映射存到数据库实现FilterInvocationSecurityMetadataSource接口每次请求时根据 URL 动态查找需要的权限再通过自定义的AccessDecisionManager做权限校验。这样做的好处是权限规则可以后台动态调整不用发版。代价是实现复杂度明显上升对于大多数内部系统其实有点过度设计。我建议先把静态配置玩明白、把角色权限模型理顺再考虑动态权限否则前后端一把梭排查问题时会很难受。7. 项目上线前的安全检查清单7.1 安全配置核查项项目做完之后要上线我一般会过一遍下面的清单确保没有低级失误默认密码是否全部改掉密码加密是否使用 BCryptcsrf().disable()是否适合当前场景如果还有 Session 机制要慎重关闭JWT 密钥是否存在配置文件而不是代码里硬编码token 有效期设置是否合理太长有泄露风险太短影响体验日志里有没有打印 token 或密码logger.info不小心会把请求参数打出来敏感接口是否都有权限控制特别是有没有出现“放行了/api/public/**但实际里面包含了敏感接口”的情况404 响应是否泄露了内部接口结构信息上传文件接口是否有格式限制和大小限制防止恶意上传7.2 压力测试与性能注意事项JWT 方案在无状态场景下性能很好因为它不需要查存储。但有一个代价每次请求都要做一次签名校验这个计算量比 Session 方案的查内存要贵。在高并发场景下jwt 解析的 CPU 消耗确实存在。实测下来单机 4 核 8G 的机器接口平均耗时在 20ms 左右其中 JWT 解析大概 1ms 以内性能影响几乎可以忽略。但如果你做了“每次请求都查一次用户表和角色表”那性能损耗就明显了。我在项目里加了 Redis 缓存用户信息key 是用户 IDvalue 是权限集合过期时间 30 分钟能显著减少数据库压力。另一个容易被忽略的点SecurityContextHolder在非 Web 线程里不会自动清理。如果你的项目用了Async一定要设置SecurityContextHolder.setStrategyName(SecurityContextHolder.MODE_INHERITABLETHREADLOCAL)否则子线程里读不到当前用户。或者更好的做法是异步任务入口显式传入必要参数。8. 一些经验总结这套 Spring Security 改造方案在我手头的项目里跑了接近半年期间经历了权限模型调整、角色新增、接口放行规则修改整体看下来当初选型是对的。框架确实上手成本高但一旦你理解了过滤器链和认证授权分离的思想后面就顺了。最后说一个我实际受益很大的习惯从头到尾保持一页纸的安全设计文档记录下自己为什么要关 CSRF、为什么用 JWT、哪个接口放行、哪个角色有什么权限。写文档的过程本身就是梳理思路的过程而且后来接手项目的人会非常感谢你。我见过太多安全配置散落在代码里、没有文档的项目全靠一个核心开发脑内记忆一旦人员变动整个安全体系就变成了黑盒。如果你正在做前后端分离的改造或者被 Spring Security 折腾得焦头烂额我希望这篇文章能帮你少走一些弯路。核心的思想记住认证确定身份、授权控制行为前者用 JWT 过滤器解决后者用 URL 规则和方法注解配合。把这几个点落地了项目的安全框架就算立住了。
