目录

• 横向对比：四大存储方案
• 适用场景总结

横向对比：四大存储方案

这张表格从关键维度对 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等)
性能影响	高 (随请求发送，增加请求体积)	低 (不影响网络请求)	低 (不影响网络请求)	低 (异步操作，不阻塞主线程)

---

适用场景总结

根据上述对比，可以清晰地为每种技术找到最适合它的"舞台"。

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 文件、图片、字体等，实现"秒开"体验。
  • 复杂应用的状态管理： 对于一些功能极其复杂的单页应用，可以用它来存储和管理整个应用的状态树。