HTML本身不存储数据，所谓“HTML存储容量上限”实为浏览器对Web Storage API（如localStorage、sessionStorage）的实现限制，典型错误QuotaExceededError源于写入超配额（普遍5–10MB，按UTF-16字节计），中文/emoji加速占满；二者接口一致但生命周期不同，localStorage持久化适合用户偏好，sessionStorage仅限当前会话；敏感信息禁存，跨域iframe隔离；突破限制可用IndexedDB、压缩、分片或服务端兜底；配额动态变化，需实测。
HTML 本身不存储数据，所谓“HTML 存储容量上限”实际是浏览器对 localStorage、sessionStorage 等 Web Storage API 的实现限制——不是 HTML 的限制，而是运行环境（浏览器）的硬约束。
为什么 localStorage 会报 QuotaExceededError
这是最典型的容量超限错误，发生在写入操作时。不同浏览器默认配额不同，但普遍在 5–10 MB 之间（注意：是字符串 UTF-16 字节长度，不是字符数）。
-
localStorage.setItem('key', 'a'.repeat(6e6))在 Chrome 中大概率触发QuotaExceededError - 值中含中文、emoji 会更快占满配额（一个 emoji 占 2–4 字节）
- 部分浏览器（如 Safari 无痕模式）会直接禁用
localStorage，此时调用即抛错，而非配额不足 - 配额计算包含 key 名 + value 字符串，全部按 UTF-16 编码字节计数，可用
new TextEncoder().encode(str).length粗略估算
localStorage 和 sessionStorage 的容量差异与使用场景
二者接口一致，但生命周期和配额策略有微妙区别：
- 多数浏览器对
sessionStorage和localStorage给出相同配额，但sessionStorage数据随标签页关闭自动清空，适合临时缓存（如表单草稿、筛选状态） -
localStorage持久化保存，适合用户偏好、登录态 token（需配合httpOnlyCookie 做安全兜底） - 不要用它们存敏感信息（如密码、完整 ID），因为 JS 可读可篡改
- 若页面嵌套 iframe 且跨域，父页与子页的
localStorage完全隔离，互不可见
突破 5MB 限制的可行替代方案
真需要存更多结构化数据时，得换机制，而不是硬塞：
立即学习“前端免费学习笔记（深入）”；
- 用
IndexedDB：浏览器原生支持的异步数据库，配额通常是磁盘空间的 50%（Chrome 最低 1GB 起），适合存大量 JSON、二进制 blob（如离线图片） - 压缩再存：对长文本做
lz-string或pako压缩后写入localStorage，能提升 60–80% 有效容量，但增加 CPU 开销 - 分片存储：手动把大对象切块，用
key_0、key_1分别存，读取时合并——仅建议临时过渡，维护成本高 - 服务端兜底：前端只存轻量标识（如
cache_id），真实数据走 API 存后端，配合 ETag/Cache-Control 控制时效
真正容易被忽略的是：配额不是静态数字，它会动态变化。比如 iOS Safari 在存储压力大时可能主动回收旧数据，而 Chrome 对同一站点所有子域名共享配额。上线前务必在目标设备上实测写入极限，别依赖文档写的“理论值”。
