JWT是客户端自持的签名断言，前端存取token并带入Header；Session是服务端维护的状态快照，前端仅自动传递HttpOnly Cookie，两者核心区别在于状态归属与失效控制能力。
JavaScript 应用中，所谓“Session”本身不是 JavaScript 提供的原生机制，而是前端配合后端会话策略的一种协作方式。真正要对比的，是前端如何适配两种主流后端认证模式：基于 JWT 的 Token 认证，和基于服务端 Session ID 的传统会话方案。选型关键不在前端代码多寡，而在于状态归属、可控性与业务约束是否匹配。
Token 认证（如 JWT）：前端只传、不存状态
JWT 本质是把用户身份和权限“打包签名”后交给前端保管。JavaScript 端只需做三件事：登录后存 token（localStorage 或 sessionStorage）、每次请求自动带入 Authorization Header、登出时清除本地 token。
- 不需要操作 Cookie，对跨域、移动端、非浏览器环境天然友好
- token 解析可完全在前端完成（如读取 exp、user_id），适合做免查接口的权限判断
- 但无法主动作废——改密码、踢设备等操作，后端只能靠黑名单或缩短过期时间兜底
- 注意：payload 是 Base64 编码，不可存放密码、身份证号等敏感字段，仅适合放 user_id、role、exp 等公开信息
传统 Session 方案：前端被动配合 Cookie 流程
Session 的核心是服务端生成并维护会话，前端只是忠实传递一个名为 sessionId 的 Cookie。JavaScript 中几乎不用手动管理它——浏览器自动携带，登出由后端清 session + 前端清 cookie 即可。
- 前端代码极简：通常无需读写 token，也不用拼接 Authorization 头
- 服务端可随时失效任意会话（比如重置密码时删 Redis 中该用户的全部 session key）
- 依赖 Cookie，需配置
SameSite、HttpOnly、Secure等属性防攻击；对 APP 或跨域 API 调用支持弱 - 如果项目用 Axios/Fetch，记得开启
credentials: 'include'，否则 Cookie 不会发送
选型看这三点实际约束
不看概念，看落地时绕不开的问题：
立即学习“Java免费学习笔记（深入）”；
- 是否需要即时踢人？比如员工离职、密码修改后旧设备立刻登出 → Session 更直接；JWT 需额外维护 Redis 黑名单，增加复杂度
- 是否面向多端？Web、APP、小程序共用一套认证？→ JWT 更统一；Session 往往得为 APP 单独设计 token fallback 逻辑
- 是否已有成熟 Session 基础设施？比如公司统一用 Spring Session + Redis 管理会话 → 改 JWT 意味着重构认证网关、刷新逻辑、前端拦截器
混合思路：不是非此即彼
现实中不少团队采用折中路径：
- 主流程走 JWT，但关键操作（如支付、改密）强制二次验证，绕过 token 直连 Session 校验
- 用短期 JWT（如 15 分钟）+ 长期 Refresh Token（存 HttpOnly Cookie），既保体验又控风险
- 前端统一封装 auth 模块，内部根据环境变量或响应头自动识别是走 Bearer 还是 Cookie 模式，上层业务无感
