Cookie 超4KB易被截断或丢弃且拖慢响应，应改用localStorage（持久，5–10MB）、sessionStorage（标签页级，5–10MB）或IndexedDB（结构化/大容量/异步，GB级）；身份凭证须用HttpOnly Cookie，禁存localStorage。
Cookie 体积超过 4KB 就可能被截断或触发浏览器静默丢弃，且每次 HTTP 请求都会自动携带，直接拖慢首屏和 API 响应。别再往 document.cookie 里塞 token、用户偏好甚至 JSON 字符串了——HTML5 提供了更合理、更大容量、更可控的替代方案。
localStorage 和 sessionStorage 能存多少？有什么区别？
两者都提供约 5–10MB 容量（具体取决于浏览器，Chrome/Firefox 通常为 10MB），远超 Cookie 的 4KB 上限。关键区别在生命周期：
-
localStorage：持久存储，除非手动调用localStorage.removeItem()或清空浏览器数据，否则一直存在 -
sessionStorage：仅限当前标签页生命周期，关闭标签即清除，适合临时状态（如表单草稿、向导步骤） - 都不随 HTTP 请求发送，不增加网络开销
- 只支持字符串，存对象必须先
JSON.stringify()，取时要JSON.parse()
localStorage.setItem('user', JSON.stringify({ id: 123, theme: 'dark' }));
const user = JSON.parse(localStorage.getItem('user'));
IndexedDB 适合存什么？比 localStorage 强在哪？
当你要存结构化数据、大量文本、二进制（如离线图片）、或需要索引/查询能力时，IndexedDB 是唯一可行的客户端数据库方案。它不是简单 key-value，而是支持事务、游标、多对象仓库（objectStore）和键范围查询。
- 容量通常为硬盘空间的 50%（Chrome）或无硬上限（Firefox），实际可用几十 MB 到 GB 级
- 异步 API，不会阻塞主线程；但写法比
localStorage复杂，需处理open、transaction、objectStore等流程 - 不支持直接存函数、undefined、DOM 节点等非可序列化值
- 注意：Safari 对 IndexedDB 的
deleteDatabase和升级逻辑有兼容性坑，建议用idb这类轻量封装库
如何安全迁移 Cookie 数据到本地存储？
不能简单把 document.cookie 里的值复制过去就完事。重点是识别用途并分类处理：
立即学习“前端免费学习笔记（深入）”；
- 身份凭证（如
auth_token）→ 改用HttpOnly+SecureCookie（后端发），前端只通过fetch自动携带；绝不要存进localStorage（XSS 可窃取） - 用户设置（如语言、主题）→ 可安全存
localStorage，并监听storage事件实现多标签同步 - 临时会话态（如购物车未提交项）→ 优先用
sessionStorage，避免跨标签污染 - 大段结构化数据（如离线文章缓存）→ 必须上
IndexedDB，别硬塞进字符串型存储 - 迁移时加版本号字段（如
__storage_v2），避免旧数据格式导致解析失败
真正难的不是“怎么存”，而是判断哪类数据该走哪条路——尤其身份凭证和本地缓存的边界。很多人把 token 存进 localStorage 图省事，结果一个 XSS 漏洞就全泄露了。别为了减 Cookie 体积，换来更大的安全漏洞。
