在现代 前后端分离架构 中，我们常常会把服务器返回的 Token（通常是 JWT）保存在客户端，然后在后续的 API 调用中携带它来进行用户身份验证。但是，这些 Token 应该存在哪里？Cookie、localStorage 还是 sessionStorage？这篇测评将给出清晰对比与推荐。
存储选项概览
前端可以把 Token 存放在以下三种主要位置：
- Cookie：浏览器自动在请求中发送，可配置安全属性
- localStorage：持久化存储，数据不会因浏览器关闭而消失
- sessionStorage：会话级别存储，只在标签页打开期间存在
每种方式的生命周期、访问权限及安全特性不同，适合的场景也不一样。
Cookie：安全性优先
优点：
- 可设置
HttpOnly，客户端 JavaScript 无法读取，从而有效阻止 XSS 攻击读取 Token。 - 可设置
Secure标志，仅在 HTTPS 下传输。 - 可设置
SameSite用于防护 CSRF。 - 浏览器会自动随请求发送，简化接口调用。
缺点：
- 容量受限（一般单域名 ~4KB）。
- 自动发送导致每次请求都携带，可能增加请求开销。
- 如果只依赖 Cookie，需要妥善处理 CSRF 风险。
推荐场景：高安全性要求（如金融、企业中后台），需要服务端管理 Session 或 Token 时。
localStorage：最常用但有风险
优点：
- 持久化：关闭浏览器仍保留数据，适合“记住我”场景。
- 容量大：相比 Cookie 可存更多数据。
- 操作简单，可由前端灵活控制。
缺点：
- 数据可被 JavaScript 读取，因此容易受到 XSS 攻击 窃取。
- 不会自动过期，需要自行管理过期逻辑。
- 不能自动带到 HTTP 请求头，需要手动写代码放到
Authorization中。
安全考量：如果站点存在输入未净化等 XSS 漏洞，Token 在 localStorage 中可能被恶意脚本窃取。
推荐场景：快速开发、前后端分离小型项目、Token 生命周期较长且团队能做好 XSS 防护。
sessionStorage：临时但较安全
优点：
- 生命周期仅限浏览器标签页，关闭即删除，降低长期泄露风险。
- 像 localStorage 一样操作简单。
缺点：
- 仍然容易被 XSS 获取。
- 不同标签页不共享数据，用户打开新标签需要重新登录或处理跨标签页通信。
推荐场景：对持久化无需求的临时登录状态（如访客模式、短会话）。
一些实战建议
安全优先
如果业务敏感性高，优先使用 HttpOnly + Secure Cookies 存储 Token 或至少存 Refresh Token 在 Cookie、Access Token 在内存里。
业务效率优先
对大多数前后端分离应用，可以选择 localStorage + XSS 防护（如 CSP 策略） 的组合，但要特别注意安全。
混合方案更灵活
大型系统可采用双 Token 方案：
- 短期 Access Token 存放在内存/SessionStorage
- 长期 Refresh Token 存放在 HttpOnly Cookie
这样即使 Access Token 被窃取，其生命周期也很短。
总结
不同存储方式各有优缺点，选择时应结合安全性、业务需求和开发成本进行权衡。在实际项目中，合理使用 Cookie、localStorage 和 sessionStorage，并搭配安全措施（如 CSP、输入净化）才能达到最佳效果。