一、两条标准路线日常开发二选一路线 1Cookie Session有状态会话流程回顾登录成功 → 服务端生成 Session图2存入 Redis / 内存通过Set-Cookie请求头发送sessionID 到浏览器端(图1)浏览器会在每次请求中自动携带Cookie服务器根据 sessionId 查询会话数据核心 ✅ Cookie 浏览器传输载体✅ Session 服务端保存会话数据路线 2Token典型 JWT无状态认证流程回顾登录返回 Token 字符串前端把 Token 存在 localStorage / Cookie 注意Token也是可以存储在Cookie中的前端手动在 HeaderAuthorization: Bearer xxx携带服务端校验签名不需要服务端存储会话二、登录场景案例方案 1Cookie Session 完整流程整体原理登录后服务端生成唯一 SessionIdSession 数据保存在服务端Redis / 内存服务端通过Set-Cookie把 SessionId 下发浏览器后续请求浏览器自动带上 Cookie。步骤 1用户登录请求POST /login Content-Type: application/json { username:zhangsan, password:123456 }步骤 2服务器处理校验账号密码正确生成唯一 SessionIdsess_987654321abc服务端存储 SessionMock Redis 数据Key: sess_987654321abc Value: {userId:1001, username:zhangsan, role:user, loginTime:2026-08-04} Expire: 30分钟步骤 3下次访问需要鉴权的接口例如 /user/info浏览器自动携带 Cookie不需要前端手动处理请求自动带上GET /user/info Cookie: SESSIONIDsess_987654321abc步骤 4服务端逻辑读取 Cookie 里的SESSIONID→ 查询 Redis 找到会话数据 → 识别用户是 zhangsan正常返回信息。步骤 5退出登录服务端删除 Redis 中sess_987654321abc这条数据会话失效。缺点集群部署需要 Session 共享跨域场景 Cookie 传递麻烦。方案 2Token (JWT) 方案【方式 AToken 存在 LocalStorage】整体原理登录成功服务端生成一段自包含信息的 JWT 字符串服务端不保存会话。 前端自己存储 Token每次请求手动放到请求头 Authorization。步骤 1登录请求和上面一样POST /login { username:zhangsan, password:123456 }步骤 2服务端校验账号密码生成 JWTMock Token此处简化模拟 JWT 字符串真实 JWT 由三段 Base64 签名组成返回给前端{ code:200, token:eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEwMDEsInVzZXJuYW1lIjoiemhhbmdzYW4iLCJyb2xlIjoidXNlciIsImV4cCI6MTc4MDQwMDAwMH0.Sdfsdf234sdf }步骤 3前端存储前端 JS 把 token 存入浏览器localStoragelocalStorage.setItem(token,eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9......)步骤 4请求受保护接口 /user/info前端手动组装 Header发送请求GET /user/info Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEwMDEsInVzZXJuYW1lIjoiemhhbmdzYW4iLCJyb2xlIjoidXNlciIsImV4cCI6MTc4MDQwMDAwMH0.Sdfsdf234sdf步骤 5服务端处理获取 Header 中的 token校验签名不需要查 Redis / 数据库解码得到内置数据userId:1001,username:zhangsan判断是否过期返回用户信息⚠️关键点服务端没有保存这份 token 信息无状态步骤 6退出登录单纯前端删除 localStorage 里的 token 即可 缺陷token 没过期前服务端无法主动让它失效需要维护黑名单 Redis方案 3混合模式【Token 存入 Cookie企业常用安全方案】很多项目为了防 XSS 攻击把 JWT 放到 CookieHttpOnly 区分于 CookieSession Cookie 里放的是Token 字符串不是 SessionId流程区别登录成功 →Set-Cookie: access_tokenxxxxJWT; HttpOnly浏览器自动携带 Cookie服务端读取 Cookie 拿到 JWT校验签名 ✅ 载体是 Cookie认证方案却是 Token 路线 充分证明Cookie 只是存储工具不和 Session 绑定死。三、JWT的优缺点✅ JWT 的优点无状态服务端不用存储会话用户信息直接放在 token 里面服务端只需要校验签名不用去 Redis / 数据库查会话记录。扩容简单多台机器不需要做会话共享天然适合分布式、微服务。跨端友好移动端、小程序、前后端分离项目都能用不像 Cookie 受浏览器同源策略限制。减少数据库 / 缓存查询压力解析出 token 就拿到用户信息不用每次请求根据 sessionId 查询用户。扩展性强可以在 payload 里携带用户角色、权限等附加信息。⚠️ JWT 缺点面试官大概率追问一并记Token 一旦下发无法直接作废。除非维护黑名单否则有效期内一直可用不能存敏感数据payload 只是 base64 编码不是加密前端可以解码看到内容体积更大每次请求都要携带网络开销比单纯 sessionId 大刷新 token 机制需要额外设计。