Web Storage、Cookies 和 IndexedDB 各司其职协同工作：Cookies 专用于服务端会话（如 HttpOnly token），Web Storage 管理前端轻量状态（如 UI 设置），IndexedDB 处理大规模结构化离线数据（如笔记正文）。
Web Storage（localStorage 和 sessionStorage）本身不直接与 Cookies 或 IndexedDB 通信，但三者可在同一应用中按职责分工协同运作——不是靠技术联动，而是靠设计约定和数据分层。
按角色划分存储边界
明确每种机制的“本职工作”，是协同的前提：
-
Cookies：专用于维持服务端会话状态。比如登录凭证（含
HttpOnly+Secure的 token）、CSRF 防护票据、用户偏好标识（如theme=dark）等。它随每次 HTTP 请求自动发送，因此只存必要字段，严格控制大小（≤4KB）。 -
Web Storage：负责前端轻量级、高频读写的客户端状态。例如页面折叠状态、表单草稿、深色模式开关、已选语言、最近搜索关键词。数据不发往服务端，容量约 5MB，支持同步 API（
setItem/getItem），适合快速响应交互。 - IndexedDB：承载结构化、离线优先的大规模数据。如待同步的聊天记录、缓存的离线文章、用户本地编辑的文档、带索引的相册元数据。它支持事务、游标遍历、多对象仓库，但 API 异步且较复杂，不适合简单键值场景。
典型协同场景示例
一个笔记类 WebApp 的数据流转可体现三者配合逻辑：
- 用户登录后，服务端通过
Set-Cookie下发auth_token（HttpOnly+Secure），浏览器自动携带该 Cookie 发起后续 API 请求； - 前端将用户当前选中的笔记本 ID、编辑器缩放比例、是否启用实时预览等 UI 状态，存入
localStorage，关页再开仍保持一致； - 所有笔记正文、附件元信息、标签关系等结构化内容，由 IndexedDB 管理；当网络恢复时，通过监听 IndexedDB 中待同步标记，调用带 auth Cookie 的接口批量提交变更。
避免常见误用冲突
协同失效往往源于职责错位：
- 不要把大段笔记内容塞进 Cookie——会拖慢每个请求，且易被截断；
- 不要用
localStorage存敏感 token——它可被 XSS 脚本直接读取，而HttpOnlyCookie 无法被 JS 访问； - 不要为“记住用户名”这种简单需求引入 IndexedDB——过度设计，增加维护成本；
- 若需跨窗口通知状态变更（如 A 标签页登出，B 标签页同步失效），可用
localStorage触发storage事件，而非依赖 Cookie 变更（Cookie 修改不触发该事件）。
安全与清理策略需统一考虑
三者生命周期不同，但用户感知应一致：
- 用户点击“退出登录”时，除清除服务端 session，前端应：
✓ 删除localStorage中所有用户专属键（如user_settings）；
✓ 清空 IndexedDB 对应数据库（或清空 objectStore）；
✗ 不手动删 Cookie（由服务端响应Set-Cookie: expires=Thu, 01 Jan 1970 00:00:00 GMT处理）； - 隐私模式或手动清除浏览数据时，浏览器默认一并清除三者，无需额外干预；
- 长期未使用的 IndexedDB 数据可定期通过时间戳索引清理，而
localStorage无内置过期机制，需自行在写入时附带有效期并读取时校验。
