2.0 KiB
是的，Spring Security 在每次带有 token 的请求中，确实都会走一遍认证流程，但并不一定每次都“存储”认证信息，具体行为取决于你使用的 token 类型（如 JWT、Session、OAuth2 等）和安全配置。
一、JWT（常见于无状态登录） 如果你使用的是 JWT（JSON Web Token）这种无状态认证机制：
每次请求都要带上 token（通常放在 Authorization Header 中）
Spring Security 会通过一个过滤器（如 OncePerRequestFilter）解析这个 token
验证 token 的有效性（比如签名、过期时间）
从 token 中解析用户信息（如用户名、角色），然后在当前请求的 SecurityContext 中构建认证对象
请求处理完后，SecurityContext 是线程局部的，不会跨请求存储，下次请求又要重新走这个流程
✅ 好处是服务无状态、扩展性强 ❌ 每次请求都要解析和验证 token，有一定性能开销
二、Session（默认方式） 如果你使用的是 Spring Security 默认的基于 Session 的认证机制：
登录成功后服务端会生成一个 SessionId，并将其通过 Cookie 返回给客户端
客户端下次请求自动带上 Cookie
Spring Security 会通过这个 SessionId 直接从服务端 Session 中获取用户的认证信息
如果存在有效 Session，就不需要重新认证，不走身份验证流程
✅ 好处是性能较高 ❌ 缺点是服务有状态，不利于分布式部署（需共享 Session）
三、OAuth2 Token（Resource Server 模式） 如果你用的是 OAuth2，比如使用 spring-security-oauth2-resource-server：
每次请求带上 Bearer Token
Spring Security 会通过配置好的 JwtDecoder 验证 token（或远程调用 introspection endpoint）
同样会在请求级别构建一次 Authentication 对象，不会存储
总结 场景 每次验证 Token 认证信息是否持久化 JWT ✅ 是 ❌ 否，线程局部 Session ❌ 否，登录一次 ✅ 是，存储在 Session OAuth2 Resource Server ✅ 是 ❌ 否，线程局部