点赞 + 收藏 === 学会
“说说看，用户登录后拿到的 Token，前端应该怎么存？”
这个问题看似简单，却能清晰地分辨出一个前端开发者对安全的理解深度。是存到 localStorage？sessionStorage？还是 Cookie？又或者是内存里？不同的选择背后，是截然不同的安全考量。
今天，来聊一聊 Token 的存储之道，让你不仅知道怎么做，更明白为什么这么做。
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;
});
优点：
localStorage）：除非手动清除，否则一直存在。sessionStorage）：页面关闭即清除，更安全一点。致命缺点：
localStorage 中的所有 Token，从而窃取用户身份。结论： 不推荐，尤其对于敏感应用。 除非你的应用完全不存在 XSS 风险（但这几乎不可能），或者 Token 的安全级别要求不高。
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 协议下被发送，防止在网络传输中被窃听。优点：
HttpOnly）：无法通过 JS 读取，安全性高。Expires 或 Max-Age 设置过期时间。缺点：
结论： 是一个可行的方案，但必须配套完善的 CSRF 防御机制。
将 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 消失
优点：
缺点：
结论： 适用于安全要求极高、不介意频繁登录的场景（如银行系统）。 对于普通 Web 应用，体验不可接受。
既然没有完美的银弹，现代前端的最佳实践通常是 组合方案 和 架构优化。
这是最传统但依然非常稳健的方案。
HttpOnly、Secure 的 Cookie 来存放 Token（可以是 JWT，也可以是 Session ID）。X-CSRF-Token Header，并与 Session 中存储的值进行比对。这是目前 API 接口认证非常流行的方案，完美解决了内存存储体验差的问题。
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，用户无感知。这个方案在安全性和用户体验之间取得了绝佳的平衡，是当前众多大型应用的首选。
给你的最终建议：
localStorage 图个方便也无可厚非，但要清楚风险。HttpOnly Cookie 并配套 CSRF 防护是标准做法。HttpOnly Cookie) 的方案。安全没有绝对，只有相对的权衡。理解每种方案的利弊，并根据你的实际业务场景做出最适合的选择，才是最重要的。
