🔥面试官：用户登录后拿到的 Token，你应该怎么存？存哪里？

开篇：一个经典的面试题

“说说看，用户登录后拿到的 Token，前端应该怎么存？”

这个问题看似简单，却能清晰地分辨出一个前端开发者对安全的理解深度。是存到 localStorage？sessionStorage？还是 Cookie？又或者是内存里？不同的选择背后，是截然不同的安全考量。

今天，来聊一聊 Token 的存储之道，让你不仅知道怎么做，更明白为什么这么做。

选项一：Web Storage（`localStorage` / `sessionStorage`）

这是最直观、最容易想到的方案。

// 登录成功后
const token = 'your_jwt_token_here';
localStorage.setItem('auth_token', token);

// 后续请求时带上
axios.interceptors.request.use((config) => {
  const token = localStorage.getItem('auth_token');
  if (token) {
    config.headers.Authorization = `Bearer ${token}`;
  }
  return config;
});

优点：

简单易用：API 简单，上手快。
永久存储（localStorage）：除非手动清除，否则一直存在。
会话期存储（sessionStorage）：页面关闭即清除，更安全一点。

致命缺点：

极易受到 XSS (跨站脚本攻击) 的攻击。这是最核心的问题。如果网站存在 XSS 漏洞，攻击者的恶意脚本可以轻易地读取到 localStorage 中的所有 Token，从而窃取用户身份。

结论：不推荐，尤其对于敏感应用。 除非你的应用完全不存在 XSS 风险（但这几乎不可能），或者 Token 的安全级别要求不高。

看机会

技术大厂→机遇机会，前端-后端-测试，待遇和稳定性还不错，感兴趣试试~

选项二：Cookie

Cookie 是传统且常见的身份验证载体。

// 服务端设置 Cookie (HTTP Response Header)
Set-Cookie: auth_token=your_jwt_token_here; Path=/; HttpOnly; Secure

// 前端无需特殊处理，浏览器会自动在每次请求中携带

注意这里的两个关键属性：

HttpOnly：这是对抗 XSS 的神器。设置了 HttpOnly 的 Cookie 无法通过 JavaScript 的 document.cookie API 访问，这意味着即使发生 XSS，攻击者也无法窃取到 Token。
Secure：强制 Cookie 只能在 HTTPS 协议下被发送，防止在网络传输中被窃听。

优点：

免疫 XSS（得益于 HttpOnly）：无法通过 JS 读取，安全性高。
可控制生命周期：通过 Expires 或 Max-Age 设置过期时间。
自动管理：浏览器自动在同源请求中携带。

缺点：

容易受到 CSRF (跨站请求伪造) 的攻击。因为浏览器会自动在请求中带上 Cookie，攻击者可以诱导用户点击一个链接，从而以用户的身份发起恶意请求。
需要额外的 CSRF 防护措施，如使用 Anti-CSRF Token、验证 Origin/Referer Header 等。

结论：是一个可行的方案，但必须配套完善的 CSRF 防御机制。

选项三：内存（Memory）

将 Token 保存在 JavaScript 变量中。

let inMemoryToken = null;

// 登录成功后
const login = async () => {
  const response = await loginAPI(username, password);
  inMemoryToken = response.data.token; // 存到内存变量
};

// 请求拦截器中添加
axios.interceptors.request.use((config) => {
  if (inMemoryToken) {
    config.headers.Authorization = `Bearer ${inMemoryToken}`;
  }
  return config;
});

// 退出登录或页面刷新时，Token 消失

优点：

安全性极高：由于 Token 只存在于当前页面的内存中，关闭页面或刷新页面后 Token 立即消失。XSS 攻击者很难通过一次性注入的脚本持续地窃取到 Token（除非攻击代码常驻内存）。

缺点：

体验差：页面一旦刷新，Token 就没了，用户需要重新登录。这对于单页面应用 (SPA) 来说是致命的。

结论：适用于安全要求极高、不介意频繁登录的场景（如银行系统）。 对于普通 Web 应用，体验不可接受。

终极方案：组合拳 + 架构思维

既然没有完美的银弹，现代前端的最佳实践通常是 组合方案 和 架构优化。

实践一：Cookie（HttpOnly + Secure） + 防御 CSRF

这是最传统但依然非常稳健的方案。

后端在登录成功后，设置一个 HttpOnly、Secure 的 Cookie 来存放 Token（可以是 JWT，也可以是 Session ID）。
前端基本不用操心 Token 的存储和携带问题，由浏览器自动完成。
后端必须部署完善的 CSRF 防护策略，例如：从 Cookie 中读取 Token 或 Session ID 进行身份验证。同时，要求请求必须携带一个额外的（由后端生成并通过 API 返回给前端的）X-CSRF-Token Header，并与 Session 中存储的值进行比对。

实践二：Access Token + Refresh Token

这是目前 API 接口认证非常流行的方案，完美解决了内存存储体验差的问题。

登录：用户输入密码登录。
返回双 Token：服务端返回两个 Token： access_token：短期有效（例如 2 小时），用于请求受保护的 API。refresh_token：长期有效（例如 7 天），仅用于获取新的 access_token，不应具备API访问权限。
存储策略： access_token：存入内存。这样即使被 XSS 窃取，有效期也很短，风险可控。refresh_token：存入 HttpOnly Cookie。因为它有效期长，必须严加保护。由于其本身不直接用于业务请求，即使遭遇 CSRF，攻击者也无法用它来做任何关键操作（只能用来换一个短期的 access_token，而该 access_token 又会因为存在于内存而难以被攻击者获取）。
无感刷新：当 access_token 过期后，前端自动（通过 refresh_token）调用刷新接口获取新的 access_token，用户无感知。

这个方案在安全性和用户体验之间取得了绝佳的平衡，是当前众多大型应用的首选。

总结与建议

Web Storage	简单易用	极易被 XSS	不推荐用于存敏感 Token
Cookie	可防 XSS ( `HttpOnly` )	需防御 CSRF	传统 Web 应用（需配 CSRF 防御）
内存	安全性极高	页面刷新即失效	安全至上、不介意体验的场景
组合策略	安全与体验的平衡	架构稍复杂	现代 Web 应用最佳实践

给你的最终建议：

如果你在做的是一个简单的、内部使用的、对安全性要求不高的工具，用 localStorage 图个方便也无可厚非，但要清楚风险。
如果你在做的是一个传统的、服务端渲染的多页应用，使用 HttpOnly Cookie 并配套 CSRF 防护是标准做法。
如果你在做的是一个现代化的 SPA（如 React/Vue 应用），强烈推荐研究并采用 Access Token (内存) + Refresh Token (HttpOnly Cookie) 的方案。

安全没有绝对，只有相对的权衡。理解每种方案的利弊，并根据你的实际业务场景做出最适合的选择，才是最重要的。

——转载自：不爱说话郭德纲