jwt 不应存于 localstorage，因其易受 xss 攻击窃取；推荐使用 httponly、secure、samesite 的 cookie 存储，兼顾安全与便捷；若必须前端存储，可选 sessionstorage 并配合短时效、刷新机制与二次验证。
JWT（JSON Web Token）是一种开放标准（RFC 7519），用于在各方之间安全地传输声明（claims），常用来实现无状态的身份认证。它由三部分组成：Header（头部）、Payload（载荷）和 Signature（签名），用点号（.）分隔，形如 xxxxx.yyyyy.zzzzz。服务端签发后，客户端携带它访问受保护接口。
为什么不能把 JWT 存在 localStorage？
localStorage 是最常用但最不安全的存储位置。它的内容可被同源页面上的任意 JavaScript 读取——一旦网站存在 XSS（跨站脚本）漏洞，攻击者就能直接窃取 token 并冒充用户。即使你做了严格的内容安全策略（CSP），XSS 风险仍客观存在，尤其在使用第三方库或富文本场景下。
推荐方案：HttpOnly + Secure 的 Cookie
将 JWT 存入 HttpOnly、Secure、SameSite=Strict（或 Lax） 的 Cookie 中，是最主流且更安全的选择：
- HttpOnly：禁止 JavaScript 访问，彻底阻断 XSS 盗 token
- Secure：确保 Cookie 只通过 HTTPS 传输，防止明文泄露
- SameSite=Strict/Lax：缓解 CSRF 攻击（配合后端校验 CSRF Token 更稳妥）
- 前端无需手动管理 token，浏览器自动随请求携带，简化开发
注意：需后端在登录成功响应中设置该 Cookie（例如 Express 中用 res.cookie()，并配置对应选项）；前端 fetch 请求要带上 credentials: 'include' 才能发送 Cookie。
立即学习“Java免费学习笔记（深入）”；
如果必须用前端存储（如纯静态 SPA + 独立 API）？
当无法控制后端设 Cookie（比如调用第三方 API 或前后端完全分离部署），可退而求其次：
- 优先考虑 sessionStorage：比 localStorage 稍好，页面关闭即销毁，减少长期暴露风险
- 绝不存敏感字段到 Payload：避免在前端解码后意外泄露用户 ID、邮箱等（后端也应最小化颁发敏感 claims）
- 配合短期过期（如 15–30 分钟）+ 刷新机制（Refresh Token 存 HttpOnly Cookie）
- 关键操作前可增加二次验证（如短信/邮箱确认），降低被盗 token 的危害
额外提醒：别忽略基础防护
再好的存储方式也挡不住弱密码、未加密传输或逻辑漏洞：
- 所有登录/令牌接口必须走 HTTPS
- JWT 的 secret key 必须足够长且保密（服务端环境变量管理）
- 验证 signature 和标准字段（
exp,nbf,iss）不可跳过 - 登出时后端应主动废止 token（例如加入 Redis 黑名单），不能只删前端存储
基本上就这些。安全不是选一个“最牛”的方案，而是根据架构权衡风险、堵住常见缺口。HttpOnly Cookie 是目前平衡安全性与可用性的最优解。
