前面我们已经从总览层面讲过网络与存储，这一篇要把“浏览器侧如何保存和复用数据”进一步拆深。很多项目一开始只是简单地把 token、主题配置、列表筛选条件存起来，后来功能越来越多，才发现浏览器侧数据已经变成一团：有些存在 cookie，有些在 localStorage，有些需要离线可用，有些过期了却没人清，缓存命中和失效也没有统一策略。
所以这一篇不再停留在“这些 API 怎么用”，而是要回答更关键的问题：浏览器为什么提供多种存储机制，它们适合承载什么类型的数据，缓存为什么总会和一致性问题绑在一起，离线思路到底该如何理解。
为什么浏览器不会只给你一种存储方式？
因为浏览器要承载的数据类型和使用场景差异很大。会话身份、短期页面状态、长期偏好、结构化大数据、离线能力、资源缓存，需求完全不同。如果所有东西都塞进一种机制里，要么能力不够，要么安全和性能代价过高。
从工程角度看，多种存储方式不是麻烦，而是在提醒你做更明确的判断：这份数据是谁的真相，保存多久，是否敏感，是否需要跨请求传输，是否需要结构化查询，是否允许脱离网络继续使用。
cookie 的核心角色不是“本地存字符串”
cookie 最大的特殊性在于，它不只是浏览器本地可读写的一段值，而是会参与浏览器与服务端之间的请求通信。这让它在会话、身份和某些请求上下文协作中仍然非常重要。也正因为如此，cookie 不能只从“前端方便不方便”去理解，还要和域、路径、SameSite、是否仅服务端可读等安全属性一起看。
在项目里，cookie 往往不适合承担大量纯前端状态，但非常适合与服务端协同管理的会话型信息。你越早把这条边界理解清楚，后面越不会把 cookie 用成杂物箱。
Web Storage 为什么适合轻量状态，而不是一切都往里放？
localStorage 和 sessionStorage 读取简单、使用方便，所以很容易被滥用。它们确实适合存储用户偏好、轻量级界面状态、少量缓存标记等，但并不意味着任何数据都该往这里塞。几个很重要的判断标准是：
- 数据是否敏感；
- 数据是否需要长期稳定保存；
- 数据是否需要复杂查询；
- 数据量是否可能明显增长；
- 数据真相是否仍然在服务端。
如果这些问题不想清楚，本地存储很容易从“提高体验的工具”变成“制造状态分叉的源头”。
项目里最常见的“缓存分层”应该怎么理解？
很多浏览器项目其实天然存在多层缓存：接口层缓存、浏览器存储层缓存、静态资源缓存、内存中的运行时状态缓存。问题不在于有没有缓存，而在于这些缓存各自解决什么问题。如果所有缓存都没有明确职责，就会出现一种典型混乱：页面刷一次是旧数据，切页回来又是另一套数据，退出登录后某些状态还残留在本地。
一个更稳的思路是先分层：
- 短期页面状态优先放运行时内存或局部状态；
- 跨刷新但不敏感的轻量数据才考虑 Web Storage；
- 与请求绑定的身份和会话信息优先按鉴权方案统一处理；
- 更复杂的大数据和离线能力再考虑 IndexedDB。
只要分层清楚，后面很多缓存失效问题会好处理很多。
IndexedDB 为什么值得单独看？
很多人一听到 IndexedDB 就觉得离自己很远，但只要你的项目涉及更大体量的数据、本地草稿、离线读写、复杂缓存或浏览器端结构化数据管理，它就可能进入视野。它的价值在于，相比简单的 key-value 存储，它更适合承载结构化、本地持久化的数据。
当然，它的复杂度也更高，所以不是默认首选。真正值得用时，通常是因为：
- 数据体量和结构已经超出 Web Storage 的舒适区；
- 需要更稳定的离线数据能力；
- 需要按键或条件组织和读取本地数据；
- 项目愿意承担更高的封装和维护成本。
哪些业务场景最容易真正走到 IndexedDB？
比较典型的场景包括：离线草稿箱、大型表单暂存、浏览器端文档或图片处理中间结果、本地搜索索引、较大规模的缓存列表、需要断网继续读写的业务。你会发现这些场景有个共同点，它们都不是“存几个简单字段”，而是需要更稳定的数据组织和更长的生命周期。
也正因为如此，IndexedDB 往往意味着你在做的已经不是简单页面，而是具备一定客户端应用属性的 Web 系统。
缓存最难的永远不是“存”，而是“失效”
这是所有缓存设计里最经典也最现实的问题。浏览器侧缓存之所以难，不是因为 API 难，而是因为业务很容易变化。某些数据多久可复用、登录切换后是否还有效、服务端更新后本地缓存何时作废、用户主动刷新时该不该重新拉取，这些都直接影响正确性。
所以缓存策略一定要和业务语义一起设计。单纯为了“提速”先缓存再说，后面通常会演变成更多兼容代码和更多状态混乱。
登录切换和多账号场景为什么特别容易出问题？
因为这类场景最容易暴露“谁是真相”的问题。用户切换账号后，哪些本地缓存应该清空，哪些还能复用，哪些必须重新向服务端确认，如果没有明确规则，就可能出现账号 A 的残留信息被账号 B 看到的严重问题。很多系统在开发阶段默认只有单用户使用，等多账号、退出重登、权限切换真正发生时，缓存污染才会集中暴露。
所以只要项目存在身份切换，就必须把缓存隔离和清理策略提前设计进去。
离线思路应该怎么理解？
离线不是简单指“没网也能打开页面”，而是浏览器在一定程度上具备资源和数据的本地可用能力。真正的离线能力通常需要考虑两层：
- 资源层：页面壳和静态资源能否在离线状态下加载；
- 数据层：用户离线时能读什么、写什么、恢复联网后如何同步。
很多项目其实并不需要完整离线能力，但理解这套思路仍然有价值，因为它会倒逼你把数据真相、本地副本、同步策略和失败恢复说清楚。
草稿箱和离线同步为什么是很好的练习题？
因为它几乎把浏览器存储里最难的几个问题都串起来了：本地何时保存，联网后何时同步，冲突怎么解决，失败时如何提示，用户主动丢弃和自动恢复如何区分。只要你能把草稿箱场景想清楚，对浏览器存储和缓存的理解通常会比单纯记 API 深很多。
项目里最常见的存储问题
常见问题包括：
- 敏感信息直接暴露在可随意读取的本地存储中；
- 缓存键和过期策略没有统一规则；
- 登录态切换后，本地旧数据未清理；
- 轻量存储被拿来承担大体量结构化数据；
- 离线需求被提出来后，才发现整个系统根本没有同步边界设计。
写在最后
浏览器存储不是“把数据放哪儿”的小问题，而是前端状态设计的一部分。cookie、Web Storage、IndexedDB 和离线能力之所以要区分，本质上是在帮助你用不同的机制承载不同责任。下一篇我们继续把安全这条线拆深，看浏览器环境下真正需要警惕的风险边界。