session方案前端仅存短session id于cookie，数据全在服务端；jwt方案前端需存完整token，payload可解码但不可篡改，服务端无状态。
JavaScript 中没有“Session”这个原生对象——所谓前端的 Session，其实是浏览器自动管理的 Cookie 机制配合后端 Session 的一种协作模式。真正对比的是 基于服务端 Session 的认证方案 和 基于 JWT 的客户端令牌方案，而 JavaScript（前端）在这两种方案中扮演的是载体管理和请求携带的角色。
存储位置与状态管理方式不同
Session 方案中，前端只保管一个短小的 Session ID（通常由 Set-Cookie 自动写入），所有用户数据存在服务端。JWT 方案中，前端需主动存储整个 Token（常放 localStorage 或 sessionStorage），Token 内部已包含用户 ID、角色、过期时间等信息。
- Session ID 一般不超过 50 字符，对 Cookie 大小友好；JWT 最小也有 200+ 字符，超长 Payload 容易突破 Cookie 4KB 限制
- 前端无法直接读取 Session 数据，必须依赖每次请求后端返回或接口补充；JWT 的 payload 可用 atob() 解码查看（但不可篡改），适合前端快速获取用户身份信息
- 服务端无须为 JWT 维护会话记录，天然支持横向扩展；Session 则需 Redis 等共享存储，否则多实例部署时会话不一致
安全性与攻击面差异明显
两者在前端环节面临不同风险，防御策略也不同：
- Session 依赖 Cookie，默认易受 CSRF 攻击，需搭配 SameSite=Strict/Lax + CSRF Token 使用；若开启 HttpOnly，JS 无法读取 Session ID，XSS 影响较小
- JWT 若存于 localStorage，一旦页面存在 XSS 漏洞，Token 可被 JS 直接窃取；若改用 HttpOnly Cookie 存储 JWT，则失去 JS 可读优势，且仍需防范 CSRF
- JWT 不含敏感字段（如密码、手机号），但明文可解码，切忌在 payload 中放高危信息；Session 数据完全由服务端控制，更利于敏感信息隔离
生命周期控制能力反差大
前端能做的操作有限，但后端控制逻辑直接影响前端体验：
- Session 登出只需调用后端接口销毁服务端数据，立即生效；JWT 一旦签发就无法主动废止，前端删 token 只是本地清除，未过期的 token 仍可被重放
- 实现 JWT “软登出”，常见做法是维护 Redis 黑名单（记录已登出的 jti），但这就牺牲了无状态优势；Session 天然支持即时踢人、强制下线等运营需求
- JWT 的 exp 字段由服务端设定，前端可解析判断是否临近过期，提前静默刷新；Session 过期由服务端决定，前端通常只能被动收到 401 后跳转登录
适用前端场景有明确分界
不是技术优劣，而是匹配度问题：
- 传统 PC 管理后台、内网系统：Session 更省心，兼容老浏览器，CSRF 防御成熟，登出可控性强
- 跨域 API 调用、小程序、混合 App、微前端架构：JWT 更自然，无需 Cookie 共享，Authorization Header 统一，服务端无共享存储压力
- 需要前端快速展示用户昵称/头像/权限按钮：JWT payload 可直接解析使用；Session 需额外发请求查用户信息，或后端在响应头中附带简要信息
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
