浏览器的存储机制涵盖多种技术，目的是满足 Web 应用在不同场景下的数据持久化、缓存和离线访问需求。它们各自具有不同的存储容量、生命周期、安全策略和访问方式，理解这些机制对于构建高效、安全的前端应用至关重要。
一、浏览器存储机制分类
1. Cookie
最早期的存储机制，主要用于会话管理和身份认证。
- 容量限制：单个约 4KB，总数有限制；
- 生命周期：可设置过期时间或为会话级；
- 访问方式：由浏览器自动在 HTTP 请求头中携带，也能通过 JS 访问（除非设置 HttpOnly）；
- 安全性：可设置 HttpOnly、Secure、SameSite 防范安全风险。
2. Web Storage（LocalStorage 和 SessionStorage）
HTML5 新增的简单键值对存储方案。
- LocalStorage：永久存储，关闭浏览器数据仍保留，同源可访问；
- SessionStorage：页面会话存储，关闭标签页即清空；
- 容量：一般为 5~10MB；
- 访问方式：同步 API，容易使用但可能阻塞主线程。
3. IndexedDB
浏览器内置的底层结构化数据库，支持事务和索引，适合复杂和大容量数据存储。
- 容量：远大于 LocalStorage，通常以设备剩余空间为限；
- 访问方式：异步 API，支持复杂操作；
- 用途：离线应用、大数据缓存、文件存储等。
4. Cache Storage
由 Service Worker 管理的请求和响应缓存，用于离线和加速访问。
- 容量：较大，依赖设备和浏览器策略；
- 访问方式：异步 Promise API；
- 用途：缓存静态资源、接口响应，实现离线支持。
5. Service Worker
虽然不是存储机制本身，但作为浏览器后台代理进程，管理 Cache Storage，实现网络请求拦截和缓存策略，是现代离线应用的核心。
- 生命周期独立于页面，可在后台运行；
- 控制页面的网络请求，提供离线能力和资源预缓存；
- 可结合 Cache Storage 和 IndexedDB 进行数据管理。
二、存储机制的生命周期与访问作用域
- Cookie：基于域和路径，可设置 HttpOnly、Secure 限制访问；
- LocalStorage/SessionStorage：基于同源策略，SessionStorage 进一步限定于标签页会话；
- IndexedDB 和 Cache Storage：基于同源，支持版本控制和升级；
- Service Worker：独立于页面，能控制同源下的所有相关页面。
三、容量限制与性能影响
- Cookie 容量最小，且会随每次请求自动发送，影响网络性能；
- LocalStorage/SessionStorage 适合轻量存储，容量适中；
- IndexedDB 和 Cache Storage 容量大，适合海量数据和文件缓存；
- Service Worker 通过异步调度，避免阻塞主线程。
四、安全与隐私考虑
- Cookie 可被服务器访问，设置 HttpOnly 避免脚本窃取；
- Web Storage、IndexedDB 只能由同源脚本访问，防止跨站数据泄漏；
- Service Worker 需 HTTPS 环境，避免被恶意注入；
- 用户隐私模式下，存储行为可能受限，数据不保证持久。
五、应用场景及选择建议
- 需要与服务器频繁交互、会话维持时用 Cookie；
- 存储简单配置、少量数据用 LocalStorage；
- 页面会话临时数据用 SessionStorage；
- 大规模结构化数据和离线存储用 IndexedDB；
- 静态资源及请求缓存用 Cache Storage，配合 Service Worker 提升离线体验和性能；
- Service Worker 负责管理缓存和拦截网络请求，实现 PWA 功能。
常见考点
面试考察点通常围绕存储类型、特点、使用场景、容量限制、安全性和生命周期展开：
- 浏览器有哪些本地存储方式？分别有什么特点？
- Cookie 和 LocalStorage 的区别是什么？
- 如何安全使用 Cookie？
HttpOnly和Secure有什么作用？ - SessionStorage 和 LocalStorage 有哪些区别？
- IndexedDB 的优势和适用场景？
- 如何使用 Cache Storage 实现离线缓存？
- 存储容量限制和浏览器兼容性问题？
- 如何避免本地存储的数据被篡改或泄露？
- 存储的生命周期和访问范围如何理解？
- 同源策略对浏览器存储的影响？