4.浏览器存储方案全解
查看飞书原文 ↗2,015 字符
横向对比：四大存储方案
这张表格从关键维度对 Cookie、LocalStorage、SessionStorage 和 IndexedDB 进行了详细对比。
特性维度 | Cookie | LocalStorage | SessionStorage | IndexedDB |
容量大小 | 约 4KB | 约 5-10MB | 约 5-10MB | 巨大 (通常 > 1GB，取决于磁盘空间) |
生命周期 | 可设置过期时间，否则随浏览器会话结束 | 永久性，除非用户或应用主动清除 | 会话级，标签页或浏览器关闭后即清除 | 永久性，除非用户或应用主动清除 |
与服务器通信 | 每次 HTTP 请求都会自动携带 | 仅在客户端，不与服务器自动通信 | 仅在客户端，不与服务器自动通信 | 仅在客户端，不与服务器自动通信 |
作用域 | 同源下的所有标签页和窗口 | 同源下的所有标签页和窗口 | 仅限当前标签页 | 同源下的所有标签页和窗口 |
API 易用性 | 较差，需手动封装 document.cookie | 非常简单 (setItem, getItem) | 非常简单 (setItem, getItem) | 复杂，异步 API，基于事务 |
存储数据类型 | 字符串 | 字符串 (需用 JSON.stringify 存对象) | 字符串 (需用 JSON.stringify 存对象) | 任何类型 (字符串, 对象, 文件, Blob等) |
性能影响 | 高 (随请求发送，增加请求体积) | 低 (不影响网络请求) | 低 (不影响网络请求) | 低 (异步操作，不阻塞主线程) |
适用场景总结 (When to use what?)
根据上述对比，可以清晰地为每种技术找到最适合它的“舞台”。
1. Cookie：当数据需要被服务器知晓时
Cookie 的核心使命是维持状态，特别是让无状态的 HTTP 协议能够“记住”用户。因为它的数据会自动附加在 HTTP 请求头中发送给服务器，所以它最适合存储那些需要**前后端共享**的信息。
•
最典型的应用场景：
◦
用户身份认证： 存储 Session ID 或 Token，服务器通过它来识别用户。
◦
用户行为跟踪： 例如 Google Analytics 用它来追踪用户来源和浏览路径。
◦
购物车： 早期的购物车功能（现在更多使用 LocalStorage + 后端同步）。
2. LocalStorage：持久化的前端“仓库”
当你想在客户端存储一些不敏感、量不大、且需要长期保留的数据时，LocalStorage 是最佳选择。它是纯粹的前端存储，不会无故拖慢你的网络请求。
•
最典型的应用场景：
◦
用户偏好设置： 如网站的主题（深色/浅色模式）、语言选择等。
◦
持久化应用状态： 缓存不常变化但需要长期保留的应用数据，减少不必要的 API 请求。
◦
存储 JWT Token： 与 Cookie 存储 Session ID 类似，前端拿到 Token 后可以存入 LocalStorage，在后续请求中手动添加到请求头。
3. SessionStorage：一次性会话的“临时备忘录”
SessionStorage 的特性决定了它非常适合存储一次性会话中的临时数据。它的数据“阅后即焚”，标签页一关，数据就消失，且不会在不同标签页之间“串门”。
•
最典型的应用场景：
◦
多步骤表单： 用户正在填写一个复杂的注册或申请表单，将已填写的信息存入 SessionStorage，即使用户刷新了页面，数据也不会丢失。一旦用户提交表单或关闭标签，这些临时数据自动销毁。
◦
单页应用中，临时保存某个页面的状态，确保用户返回时能恢复之前的浏览位置或筛选条件。
4. IndexedDB：客户端的“重型数据库”
当你需要在浏览器端存储大量、结构化的数据，甚至需要进行查询、索引和事务管理时，IndexedDB 是唯一的选择。它是为构建强大的离线 Web 应用（PWA）而生的。
•
最典型的应用场景：
◦
离线应用数据存储： 如一个在线文档编辑器，可以将整篇文档内容、历史版本等存储在 IndexedDB，让用户在没有网络时也能查看和编辑。
◦
大型静态资源缓存： 缓存 Web 应用的 JS/CSS 文件、图片、字体等，实现“秒开”体验。
◦
复杂应用的状态管理： 对于一些功能极其复杂的单页应用，可以用它来存储和管理整个应用的状态树。