Session是有状态的（服务端存储会话数据），JWT是无状态的（凭证自包含、服务端仅验签）。前者适合需强控场景如强制登出，后者适用于高并发分布式系统。
JavaScript 中 Session 和 JWT 本身代表两种不同的会话管理思路：Session 是有状态的（服务端存 session 数据），JWT 是无状态的（凭证自包含，服务端不存会话）。它们不能“结合”成一种混合状态机制，但可以按需在不同场景下切换使用策略——关键在于后端设计与前端配合，而非前端 JavaScript 单独决定。
理解本质区别
Session 依赖服务端存储（如 Redis 或内存）+ 客户端 Cookie；JWT 是签名令牌，内容可验不可改，服务端只需验证签名和过期时间，不查库。
- 用 Session：适合敏感操作、需强实时控制（如强制登出、权限动态变更）
- 用 JWT：适合高并发、分布式环境，减少服务端存储压力
- “切换”不是运行时动态改协议，而是根据业务路径选择认证方式（例如登录用 JWT，管理后台用 Session）
前端如何配合切换
前端 JavaScript 不负责生成或校验 JWT/Session，只负责携带凭证。切换逻辑由后端路由或接口约定驱动：
- 登录成功后，后端返回两种响应之一：Set-Cookie（启用 Session）或 JSON { token: "xxx" }（启用 JWT）
- 后续请求中，前端自动发送 Cookie（Session）或手动在 Authorization: Bearer xxx 中带 JWT
- 可通过 URL 路径区分，例如 /api/session/** 走 Session，/api/jwt/** 走 JWT
避免常见误区
不要试图让 JWT “变成有状态”（比如把 JWT 存进 Redis 当 Session 用），这既失去 JWT 优势，又增加复杂度。也不建议前端 JS 解析或修改 JWT payload——它应被视为黑盒凭证。
- JWT 过期后必须重新登录或刷新（用 Refresh Token），不能靠前端续期
- Session 失效（如服务端清除）会立刻生效，JWT 则需等过期或配合黑名单机制
- 敏感操作（如支付、改密）建议强制走 Session 或二次验证，不单靠 JWT
简单切换示例（后端示意）
以 Express + Passport 为例：
- 登录接口 POST /login/session → 设置 httpOnly Cookie，返回空 body
- 登录接口 POST /login/jwt → 验证后签发 JWT，返回 { token: "..." }
- 中间件分别处理：sessionAuth() 检查 req.session，jwtAuth() 解析 Authorization header
不复杂但容易忽略
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
