【计算机网络】前端基础知识Cookie、localStorage、sessionStorage 以及 Token

一、先搞懂：为什么需要这些“存储工具”？

网页是“无状态”的——比如你登录一个网站，浏览器和服务器每次通信都是独立的，服务器默认记不住你是谁。为了让服务器“记住”用户状态（比如登录状态、购物车内容），或者让浏览器自己保存一些数据（比如用户偏好），就需要各种存储技术。

二、四大核心技术对比表

sessionStorage 里存储的是键值对数据，其中可能有 token，但不代表 sessionStorage 里所有内容都叫 token
auth_token里存的是后端返回的jwt数据

这里我之所以把jwt的认证数据放到sessionstorage里，而不是cookies，是因为基于 localhost 本地服务 + 多标签页共享认证 的场景，选择 sessionStorage，

用开发一个本地的多用户登录同一域名的情况来解释

比如说我为localhost:8080/merchant配置了一个商家登录页，我登陆之后，想要在新开一个标签页，登录另一个商家，在尝试后发现，页面回到了之前登陆的地方，这里体现了 localStorage的特性

localStorage 的特性

• localStorage 的特点是在同一域名下（这里是 localhost:8080 ），所有标签页都能访问和修改相同的数据。当你在一个标签页登录，使用 localStorage 存储登录信息（比如用户 ID、JWT 等），然后在另一个标签页再次登录时，新的登录信息写入 localStorage，就会覆盖掉之前存储的内容，从而导致之前的登录状态丢失。

sessionStorage 的方案分析

• 标签页隔离：sessionStorage 只在当前标签页有效，不同标签页之间的 sessionStorage 数据是相互独立的，这样可以避免不同标签页登录状态相互干扰，每个标签页可以保持各自的登录状态 ，满足你登录多个商家，且每个页面独立维护登录态的需求。

Cookie 的方案分析

• 自动发送：Cookie 会在每次 HTTP 请求时自动被发送到服务器，无需前端手动处理传递登录凭证的操作，对于后端验证登录状态非常方便。
• 安全性可配置：可以设置 HttpOnly 属性，使得 JavaScript 无法读取 Cookie 内容，大大降低了 XSS 攻击时登录凭证被盗取的风险；设置 SameSite 属性，可以有效防御跨站请求伪造（CSRF）攻击；设置 Secure 属性后，Cookie 只会在 HTTPS 连接下发送（虽然你当前是 HTTP 环境，但后续如果切换到 HTTPS ，这个属性会增强安全性）。
• 跨标签页共享：在同一域名下，不同标签页之间可以共享 Cookie，方便统一管理登录状态。(显然我要的是同一域名下，不同标签页区分不同用户所以 sessionStorage 更好) 而同域 Cookie 全局共享

三、逐个详解

1. Cookie：服务器给浏览器的“身份证”

• 工作流程：
  当你登录网站时，服务器验证通过后，会生成一个包含用户信息的 Cookie，通过响应头发给浏览器。浏览器会把这个 Cookie 保存起来，之后每次访问该网站时，浏览器都会自动把 Cookie 放在请求头里发给服务器，服务器通过 Cookie 就知道“你是谁”了。

• 举个例子：
  你登录微信网页版，服务器给你一个 Cookie 包含 userid=123。之后你刷新页面，浏览器自动把这个 Cookie 发给服务器，服务器一看 userid=123，就知道是你，不用重新登录。

  由于 同域cookies全局共享 的特性，你后续使用网页微信的 聊天功能，加好友功能，等等，这些同一域内 所有需要认证的不同路由 都不需要再输一遍账号密码了

• 关键设置：

  • expires/max-age：设置过期时间（如 max-age=604800 表示 7 天后失效）。
  • HttpOnly: true：禁止 JS 读取 Cookie（防 XSS 攻击，保护登录信息）。
  • Secure: true：仅在 HTTPS 连接时才发送 Cookie（更安全）。
  • SameSite: Strict：限制跨站请求时不发送 Cookie（防 CSRF 攻击）。

• 如何操作：
  前端 JS 可以读写非 HttpOnly 的 Cookie：

  // 写入 Cookie（简单方式，复杂设置需用 document.cookie 字符串拼接）
  document.cookie = "username=张三; max-age=604800; path=/";
  
  // 读取所有 Cookie（字符串形式，需自己解析）
  console.log(document.cookie); // "username=张三; theme=dark"
  

2. localStorage：浏览器的“长期记事本”

• 特点：存了就一直有，除非用户手动删除（比如清除浏览器数据），所有同源标签页都能共享。

• 举个例子：
  你在网站设置了“深色模式”，前端用 localStorage 存 theme: "dark"。下次打开该网站，前端读取这个值，自动显示深色模式，不用再重新设置。

• 如何操作：

  // 存数据
  localStorage.setItem("theme", "dark");
  localStorage.setItem("userPrefs", JSON.stringify({ fontSize: 16 }));
  
  // 读数据
  const theme = localStorage.getItem("theme"); // "dark"
  const prefs = JSON.parse(localStorage.getItem("userPrefs"));
  
  // 删数据
  localStorage.removeItem("theme"); // 删除单个
  localStorage.clear(); // 清空所有
  

3. sessionStorage：浏览器的“临时草稿纸”

• 特点：只在当前标签页有效，关闭标签页就自动删除，不同标签页（即使同源）也不共享。

• 举个例子：
  你在填写一个很长的表单（比如注册信息），填到一半不小心刷新了页面。如果前端用 sessionStorage 实时保存你的输入，刷新后可以读取回来，不用重新填写。

• 如何操作：和 localStorage 完全一样，只是把 localStorage 换成 sessionStorage：

  sessionStorage.setItem("formDraft", JSON.stringify({ username: "张三" }));
  const draft = JSON.parse(sessionStorage.getItem("formDraft"));
  

4. Token：API 接口的“通行证”

• 本质：服务器生成的一串字符串，包含用户身份信息（如用户 ID、过期时间），用于 API 接口的身份验证。

• 工作流程：

  1. 用户登录成功后，服务器生成 Token 并返回给前端。
  2. 前端把 Token 存在 localStorage/sessionStorage 或 Cookie 里。
  3. 之后调用 API 时，前端手动把 Token 放在请求头里（如 Authorization: Bearer xxxx）。
  4. 服务器验证 Token 有效性，有效则返回数据，无效则要求重新登录。

• 举个例子：
  你用手机 App 登录某个服务，App 会保存 Token。之后你刷首页、看消息，App 每次都会把 Token 发给服务器，证明“是已登录的用户”。

• 为什么用 Token：
  比传统 Cookie 更灵活，适合跨域场景（如前后端分离项目、App 与服务器通信）。

四、核心区别总结

1. 是否自动发给服务器：

   • Cookie：是（每次请求都带）。
   • 另外三个：否（需手动处理）。

2. 生命周期：

   • localStorage：永久（除非手动删）。
   • sessionStorage：当前标签页生命周期。
   • Cookie/Token：可设置过期时间。

3. 安全性：

   • 敏感信息（如登录凭证）优先用 Cookie（带 HttpOnly） 或 Token（存在内存，不用 localStorage）。
   • 非敏感信息（如用户偏好）用 localStorage。

4. 适用场景：

   • 登录状态维持：Cookie（传统网站）或 Token（前后端分离）。
   • 长期保存用户设置：localStorage。
   • 临时缓存：sessionStorage。

五、常见误区

1. 不要用 localStorage 存密码、Token 等敏感信息——容易被 JS 读取（XSS 攻击风险）。
2. Cookie 不是越多越好——每个 Cookie 4KB 上限，且每次请求都发送，会增加网络开销。
3. 刷新页面时，sessionStorage 不会消失（只有关闭标签页才会），而页面跳转（同域）时会保留。