用户登录后，Token 你存哪？

之前面试，面试官问了这样一个问题：“用户登录后拿到的 Token，你会存在哪里？”

于是我信心满满地回答：“localStorage 呗，简单方便。”

最怕空气突然安静。

看完对你一定有用！

天真的 localStorage 方案

很多人的第一反应：

// 登录成功后
localStorage.setItem('token', 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...');
// 请求时自动携带
axios.interceptors.request.use(config => {
  const token = localStorage.getItem('token');
  if (token) {
    config.headers.Authorization = `Bearer ${token}`;
  }
  return config;
});

看起来很美，实际上：

• 简单直观，上手快速；
• 持久化存储，页面刷新不影响；
• 但是：一旦遭遇 XSS，攻击者可以直接读取你的 Token。

致命问题：

• 前端 JavaScript 能直接读取；
• 几乎无法有效防御 XSS 窃取；
• 相当于把家门钥匙放在门口的垫子下面。

真正的解决方案

方案一：HttpOnly Cookie – 传统的智慧

服务端设置：

// 登录接口返回时设置 
CookieSet-Cookie: token=eyJhbGci...; Path=/; HttpOnly; Secure; SameSite=Strict

前端无需特殊处理：

• 浏览器会自动在每次请求中携带 Cookie；
• 前端 JavaScript 无法读取，彻底防御 XSS。

配套的 CSRF 防护：

// 方案 1：CSRF Token
const csrfToken = document.querySelector('meta[name="csrf-token"]').content;
axios.defaults.headers.common['X-CSRF-Token'] = csrfToken;
// 方案 2：SameSite Cookie + 验证 Origin 头

适用场景：

• 传统多页面应用；
• SSR 服务端渲染项目；
• 对 SPA 单页应用也完全可行；

方案二：内存存储 – 极致的安全

let memoryToken = null;
// 登录后存储
const login = async (credentials) => {
  const response = await axios.post('/api/login', credentials);
  memoryToken = response.data.token;
  return response;
};
// 请求拦截器
axios.interceptors.request.use(config => {
  if (memoryToken) {
    config.headers.Authorization = `Bearer ${memoryToken}`;
  }
  return config;
});

优势：

• 完全不持久化，免疫 XSS；
• 页面关闭即失效；
• 安全性最高。

缺点：

• 页面刷新就需要重新登录；
• 用户体验较差。

适用场景：

• 银行、金融等高安全要求应用；
• 内部管控系统。

方案三：现代 SPA 的黄金标准 – 双 Token 机制

这才是真正的平衡之道：

各方案对比

什么时候用什么？

面试官的真正期待

初级回答：

“localStorage，因为简单方便。”

中级回答：

“用 HttpOnly Cookie，因为能防 XSS，但要配合 CSRF 防护。”

高级回答：

“要看具体场景。如果是内部系统，localStorage 也可以。如果是传统 Web 应用，HttpOnly Cookie + CSRF Token 很稳定。如果是现代 SPA，我推荐 Access Token + Refresh Token 的组合方案，在安全和体验间取得平衡。”

这才是面试官想听到的：

• 理解不同方案的权衡；
• 能够根据业务场景做出合理选择；
• 清楚每种方案的安全边界。

安全的核心是平衡，不是绝对

回头看看我当初那个 naive 的 “localStorage” 回答，问题不在于技术本身，而在于思考方式。

真正的安全专家不是追求绝对安全，而是懂得：

• 在什么场景下选择什么方案；
• 每种方案的风险边界在哪里；
• 如何用合适的成本解决合适的风险。

现在当面试官再问我 “Token 该存哪里” 时，我会先反问：

“咱们的业务场景是什么？安全要求多高？用户体验期望怎样？”

以上关于用户登录后，Token 你存哪？的文章就介绍到这了，更多相关内容请搜索码云笔记以前的文章或继续浏览下面的相关文章，希望大家以后多多支持码云笔记。