浏览器存储
为什么前端工程师不能把“存储”理解成一个按钮
很多前端项目都会存数据。
但“存”这件事非常容易被说得过于笼统。
真实问题通常是：
- 存哪里
- 存多久
- 谁能读
- 会不会阻塞主线程
- 会不会被浏览器自动带上请求
- 是配置、小状态，还是大规模结构化数据
这也是为什么浏览器存储不能只讲一个 localStorage。
先把浏览器存储讲简单
浏览器存储可以先理解成：
浏览器为页面或应用提供的一组本地保存数据的能力。
但这些能力不是一个统一抽象。
它们有非常不同的目标和边界。
最容易混淆的几类能力
Cookie
最老、最常见，但也最容易被误用。
它不仅能本地保存，还会在某些请求里自动携带。
sessionStorage
以页面会话为单位的本地存储。
localStorage
更持久的键值存储。
IndexedDB
适合大量结构化数据的异步存储。
Cache API
更偏请求和响应对象缓存，不是通用数据库。
为什么 cookie 不能简单讲成“浏览器存储方案之一”
这样讲虽然不算错，但不够。
cookie 更大的特点是：
它参与 HTTP 语境。
也就是说，它不仅是“存下来”，还和请求自动携带、鉴权、会话、SameSite、安全属性有关。
这决定了它和 localStorage 根本不是同类替代关系。
localStorage 为什么常被过度使用
因为它简单。
API 非常直观。
但它的问题也同样明显：
- 同步 API
- 字符串存储
- 不适合大规模结构化数据
所以它更适合：
- 少量配置
- 主题
- 简单偏好项
而不适合把它当小数据库。
为什么“同步”这个词在 localStorage 这里很重要
因为同步意味着：
调用它的时候，主线程会被这次操作直接占用。
在数据量小的时候，这个问题可能不明显。
但如果把它用于频繁、大量读写，就会开始影响页面响应。
sessionStorage 的真正位置是什么
它更适合：
和当前 tab 或页面会话强绑定、关闭会话就可以丢掉的数据。
它不是 localStorage 的简单小版本。
它的关键语义是会话范围。
IndexedDB 为什么值得认真学
因为它是浏览器里真正更接近“本地数据库”的能力。
它更适合：
- 大量结构化数据
- 异步读写
- 按索引查询
- 离线能力
如果你在做：
- 离线应用
- 大型表单草稿
- 本地搜索索引
- 内容缓存
IndexedDB 会比 localStorage 更合理。
那为什么很多人又觉得 IndexedDB 难用
因为它的 API 心智成本明显高于 localStorage。
它有：
- 事务
- object store
- 索引
- 版本升级
所以现实里很多项目会借助封装库。
但即使使用封装，也应该知道它背后的能力边界。
Cache API 到底是什么
这是另一个非常容易被讲混的点。
Cache API 不是通用键值存储。
它更适合缓存：
- Request
- Response
也就是更偏网络对象。
这也是为什么它经常和 Service Worker、离线资源、请求响应复用一起出现。
为什么 Cache API 不该被拿来替代 IndexedDB
因为它们解决的问题不一样。
Cache API
更适合资源和响应缓存。
IndexedDB
更适合结构化应用数据。
把两者混用，会让系统语义越来越不清楚。
浏览器存储的选择，本质上在权衡什么
通常在权衡这些因素：
- 数据规模
- 生命周期
- 是否需要结构化查询
- 是否需要异步
- 是否要参与请求
- 安全敏感度
这就是为什么不存在“浏览器存储最佳方案”。
只有更适合当前数据性质的方案。
安全边界为什么必须进存储讨论
很多团队一谈存储，就只谈 API 用法。
这不够。
你还要考虑：
- 是否会被脚本读取
- 是否会自动带到请求
- 是否适合保存敏感信息
例如：
- 某些 token 放在
localStorage会增加被 XSS 读取的风险 - cookie 又会带来 CSRF 相关语境
所以存储从来不只是前端便利性问题。
为什么“浏览器会一直替你保存”也是错误直觉
不同存储能力的持久性和淘汰策略并不完全一样。
而且浏览器本地存储并不是“永远可靠数据库”。
你要接受：
- 浏览器策略
- 用户清理
- 存储配额
这些现实。
配额为什么值得知道
因为本地存储不是无限空间。
尤其当你开始存：
- 大量离线数据
- 媒体信息
- 缓存响应
配额、淘汰和失败处理就会进入工程设计。
浏览器存储和状态管理不是一回事
这是很多前端工程里常见的混淆。
状态管理更多关注：
- 当前 UI 状态
- 数据消费与同步
浏览器存储更多关注：
- 数据跨刷新、跨会话是否保留
两者可以连接，但不应该混成一套概念。
Cookie 和认证为什么总绑在一起讲
因为 cookie 天然处在 HTTP 请求链路里。
这让它在会话管理里非常常见。
但讲 cookie 时不能只讲“能不能存 token”。
还要一起讲：
HttpOnlySecureSameSite
否则就只剩半套理解。
localStorage 为什么常和主题、偏好项绑定
因为这类数据通常：
- 不太敏感
- 结构简单
- 容量小
- 跨刷新保留有价值
这非常符合 localStorage 的优势区间。
IndexedDB 为什么常和离线产品绑在一起
因为离线能力往往需要：
- 大量本地数据
- 异步读写
- 查询能力
这些都是 IndexedDB 更擅长的地方。
如果你做的是编辑器、知识库、协作工具、PWA，这类需求会很常见。
常见误区
1. 把 cookie、localStorage、IndexedDB 当成同类替代品
它们解决的问题并不一样。
2. 把 localStorage 当数据库
这通常会在规模和主线程压力上出问题。
3. 把 Cache API 当通用对象仓库
它更适合请求与响应。
4. 只看便利性，不看安全边界
这是非常危险的习惯。
中国互联网语境里的现实情况
在很多业务里，浏览器存储会和这些场景绑得很紧：
- 登录态
- 用户偏好
- 表单草稿
- WebView 环境中的轻量缓存
同时还经常会遇到：
- 多容器环境
- 第三方 WebView
- 不同浏览器策略差异
这会让“能不能稳定保存”和“安全边界是否清楚”都变得更重要。
海外产品语境里，为什么 IndexedDB 和离线能力更常被认真对待
因为很多 SaaS、协作工具和 PWA 语境里，本地数据层是产品能力的一部分。
这时 IndexedDB、Cache API、Service Worker 会被放在同一条离线能力链路上看。
这很值得借鉴。
因为它会迫使你从系统角度而不是“顺手存一个值”来理解浏览器存储。
这类主题为什么很适合做表达训练
因为它很容易被讲成：
- localStorage 持久化，sessionStorage 会话级
这太薄了。
更好的表达应该继续说明：
- cookie 为什么不是普通本地存储
- localStorage 为什么同步是一个重要限制
- IndexedDB 和 Cache API 各自解决什么问题
- 安全边界为什么要跟存储一起讲
建议实践
实践 1：做一个存储能力对照 demo
练什么：
建立不同存储能力的边界直觉。
最小交付物：
一个同时演示 cookie、localStorage、sessionStorage、IndexedDB 的 demo。
验收标准：
- 能说明各自生命周期
- 能说明哪类数据适合放哪里
常见误区：
- 只会写入和读取，不做场景判断
实践 2：用 IndexedDB 做一个离线草稿箱
练什么：
理解结构化数据本地存储。
最小交付物：
一个支持刷新恢复的草稿功能。
验收标准：
- 数据量上来后仍然稳定
- 不依赖同步阻塞式存储
常见误区：
- 用 localStorage 勉强堆出同类效果
实践 3：比较 cookie 与 localStorage 的安全讨论
练什么：
把存储选择和安全边界放在同一框架里考虑。
最小交付物：
一份认证信息存储方案对照说明。
验收标准：
- 能说明 XSS 与 CSRF 语境差异
- 不把某个方案说成绝对银弹
常见误区：
- 只看“前端拿不拿得到”，不看整体攻击面