Web Storage容量为5–10MB但按UTF-16字节计算，中文字符占2字节；严禁存储敏感信息，因其明文存于本地且易受XSS窃取；sessionStorage与localStorage安全差异极小；超2MB或需查询时应改用IndexedDB或服务端存储。
Web Storage 的容量限制和实际可用空间
大多数浏览器对 localStorage 和 sessionStorage 的单源（origin）配额是 5–10 MB，但这个值不是固定标准，而是由浏览器动态分配的。Chrome 实际常给约 6.5 MB，Firefox 约 10 MB，Safari 在 iOS 上甚至低至 2.5 MB 且会主动清理空闲数据。
关键点在于：这个“限制”是按字符串 UTF-16 编码字节数计算的，不是字符数。一个中文字符占 2 字节，JSON.stringify() 后的双引号、逗号、空格都会计入。你存一个 4 MB 的对象，可能调用 localStorage.setItem('key', JSON.stringify(obj)) 就直接抛出 QuotaExceededError。
- 写入前先估算：
function estimateSize(obj) { return new Blob([JSON.stringify(obj)]).size; } - 捕获异常并降级：用
try...catch包裹setItem，失败后可尝试压缩（JSON.stringify(obj, null, 0)去空格）、删旧键、或 fallback 到 IndexedDB - 不要依赖
localStorage.length或遍历localStorage.key(i)来“清空所有”，这在大容量下性能极差；改用明确的 key 命名约定（如加前缀myapp:cache:）再逐个移除
localStorage 为什么不能存敏感信息
localStorage 是纯前端同步 API，数据以明文形式存在用户本地磁盘文件中（例如 Chrome 的 Local Storage/ 目录），任何能访问该浏览器 profile 的人，或已注入脚本的页面（XSS），都能立刻读取全部内容。
它不参与 HTTPS 加密传输，也不受 CSP 的 script-src 限制——只要脚本能运行，就能调用 localStorage.getItem()。所以：
- 绝对不要存 token、密码、身份证号、支付信息等原始敏感字段
- 即使加密后存入，密钥若硬编码在 JS 里，等于没加密（攻击者可直接解密）
- OAuth
refresh_token同样不行——它本就应由后端保管，前端只持短期access_token，且应存在内存变量中，页面刷新即丢
sessionStorage 与 localStorage 的安全差异其实很小
很多人误以为 sessionStorage 更安全，因为它随标签页关闭而销毁。但现实是：只要页面还在运行，它的数据和 localStorage 一样可被同源任意脚本读写；而且它不支持跨标签页共享，反而导致开发者为绕过限制而把数据塞进 URL 或 postMessage，引入新风险。
真正有意义的区分点只有生命周期，而非保密性：
-
sessionStorage适合临时状态：表单草稿、向导步骤、未提交的筛选条件 -
localStorage适合用户偏好：主题色、语言、折叠面板状态 - 两者都不该用于身份凭证缓存。需要持久化登录态，请用
HttpOnly + Secure的 cookie 配合后端 session 管理
替代方案：什么时候该换 IndexedDB 或服务端存储
当你要存结构化数据、二进制 blob、超过几 MB、或需要事务/查询能力时，localStorage 就到头了。它只有字符串键值对，没有索引、无事务、阻塞主线程。
简单判断逻辑：
- 数据 > 2 MB 或含图片 base64 → 用
IndexedDB（配合idb库降低复杂度） - 需多设备同步（如笔记、待办）→ 必须走服务端，前端只做离线缓存（用
Cache API+Service Worker） - 要防用户手动篡改 → 没有前端方案，只能校验（如签名校验 JSON 内容哈希）+ 关键逻辑放服务端
最后提醒一句：Web Storage 不是数据库，也不是加密保险箱。它的设计目标只是“轻量、快速、同源、客户端暂存”。越清楚这点，越不容易把它用错地方。
