17370845950

localStorage适合存前端专属数据（如用户偏好、UI状态），cookie适合存需服务端参与的小型关键数据（如HttpOnly登录态）；选型依据是读取主体、时机及是否需发往服务器。

localStorage 适合存什么，cookie 适合存什么

选哪个不看“功能多不多”，而要看“谁需要读、什么时候读、要不要发给服务器”。localStorage 是纯前端的键值对存储，浏览器关了还在，但服务端完全看不见；cookie 会随每次 HTTP 请求自动带上，服务端能读能写，但有大小限制（通常 4KB）、有同源策略和安全标记（HttpOnly、Secure）约束。

常见分工：

• 用户偏好设置、UI 主题、折叠状态 → localStorage
• 登录态 token（尤其是需要服务端校验的）→ cookie（配合 HttpOnly 防 XSS）
• 临时缓存少量接口响应（且无需服务端参与）→ localStorage 或 sessionStorage
• 跨子域共享小数据（如统一登录标识）→ cookie（设 Domain=.example.com）

用 JavaScript 操作 cookie 很麻烦，别手写

原生 document.cookie 是个怪异的字符串接口：读是拼接的键值对（a=1; b=2; c=3），写要手动拼 key=value; expires=...; path=/; secure，还容易漏分号或编码错误。直接手写极易出错，比如中文没 encodeURIComponent、过期时间格式错、路径没设导致读不到。

建议用轻量库或封装函数：

• 简单项目：用 js-cookie（npm install js-cookie），一行读写：

  Cookie.set('token', 'abc123', { expires: 7, secure: true, sameSite: 'Strict' })

• 不想引入依赖：封装一个 setCookie 函数，必须处理 encodeURIComponent、默认 path=/、支持 maxAge（比 expires 更可靠）
• 绝对不要在 cookie 里存敏感信息（如密码、完整 token）——除非加了 HttpOnly 且前端只负责触发登录，不读 token 内容

localStorage 的坑比想象中多

它看起来简单，但实际用起来有几个硬伤：

• 只能存字符串：存对象必须 JSON.stringify()，取出来得 JSON.parse()，否则是 [object Object]
• 没有过期机制：不能像 cookie 那样自动失效，得自己记时间戳+手动清理
• 同步阻塞：大体积数据（>5MB）读写可能卡主线程，尤其低端设备
• 同源限制严格：子域名之间（a.example.com 和 b.example.com）完全隔离，无法共享
• 隐私模式下部分浏览器会拒绝写入（Safari 尤其激进），应加 try/catch 并降级到内存存储

示例安全写法：

try {
  localStorage.setItem('userPrefs', JSON.stringify({ theme: 'dark', lang: 'zh' }))
} catch (e) {
  // 可能是隐私模式或超出配额，fallback 到内存对象
  window._fallbackStorage = { theme: 'dark', lang: 'zh' }
}

别让 cookie 和 localStorage 做对方的工作

常见反模式：

• 把大段 HTML 片段存在 cookie 里 → 超出 4KB，请求头膨胀，拖慢所有请求
• 把 JWT 存 localStorage 后又在每个 fetch 的 Authorization 头里手动读出来 → 安全风险高（XSS 可盗），不如用 HttpOnly cookie + 后端验证
• 用 localStorage 存登录态并自己实现“过期”逻辑 → 容易因时钟误差或未清理导致状态不一致
• 在单页应用里频繁读写 localStorage 做状态同步 → 应优先用 React/Vue 状态管理，存储只做持久化兜底

真正该纠结的不是“怎么选”，而是“这个数据到底需不需要离开当前页面上下文”。如果答案是否定的，连 localStorage 都不用碰。