localstorage和cookie本质不同：前者纯前端本地存储，后者用于客户端与服务端通信；选错会导致性能下降、安全风险或浏览器限制。
LocalStorage 和 Cookie 都能存数据，但根本不是一回事——一个专为浏览器本地用，一个专为客户端和服务端通信而生。选错会拖慢请求、暴露敏感信息，甚至被浏览器限制。
性能影响：一个悄悄拖慢请求，一个完全不参与
Cookie 会随每个同源 HTTP 请求自动发送到服务器，哪怕只存了 user_id=abc，也会增加请求头体积。大量 Cookie 或高频请求时，明显抬高网络开销；而 LocalStorage 完全不参与网络传输，读写都在内存中完成，纯前端操作，无额外延迟。
- Cookie 多了 → 请求头变大 → TTFB 延长 → 页面首屏变慢
- LocalStorage 读写是同步的，但因不发请求，实际感知更快（尤其在弱网下优势明显）
- 注意：频繁读写 LocalStorage（如高频轮询）可能触发主线程阻塞，建议搭配防抖或改用 IndexedDB 处理复杂场景
容量限制：4KB vs 5MB，差了一个量级
单域名下 Cookie 总容量约 4KB（含键名、值、属性），超限会被截断或静默失败；LocalStorage 通常提供 5MB 左右空间（Chrome/Firefox 实测），足够存用户配置、离线文章列表、表单草稿等结构化数据。
- 别把 JWT Token 往 Cookie 里硬塞——base64 编码后常超 2KB，容易触顶
- LocalStorage 虽大，但只能存字符串，对象需 JSON.stringify()，取回要 JSON.parse()，注意解析错误风险
- 移动端 Safari 对 LocalStorage 的实际可用空间更保守，建议留 20% 余量
使用场景：谁该存什么，边界必须清晰
核心判断标准就一条：要不要让服务器知道这个数据？
- 用 Cookie：登录态标识（session_id）、CSRF token、带 SameSite 的跟踪标记——这些必须由服务端签发并验证，且需随请求自动送达
- 用 LocalStorage：暗黑模式开关、语言偏好、已读文章 ID 列表、离线缓存的 API 响应——纯前端逻辑需要、无需服务端参与、也不该出现在请求头里
- 禁止混用：比如把 access_token 存 LocalStorage 后直接用于 Authorization 请求头，虽可行但有 XSS 泄露风险；若存 Cookie，又得配 HttpOnly + Secure，否则 JS 读不到
安全与生命周期：一个可设过期，一个永不自动消失
Cookie 支持 expires / max-age 控制有效期，还能用 HttpOnly 阻止 JS 访问、Secure 强制 HTTPS 传输、SameSite 缓解 CSRF；LocalStorage 没有过期机制，一旦写入就一直存在，清除只能靠用户手动或代码调用 localStorage.removeItem() 或 localStorage.clear()。
- 记住密码功能 ≠ 存密码到 LocalStorage（绝对禁止），而是用 Cookie + “记住我”逻辑由后端控制长期会话
- 用户登出时，不仅要清 LocalStorage 里的用户信息，更要向后端发起退出接口，并让服务端失效 Cookie 中的 session
- 隐私模式下，LocalStorage 可能被禁用或每次启动清空，关键流程需做降级处理（如 fallback 到内存存储）
