大多数现代浏览器对 localStorage 的单域名存储上限是 5MB，但 Safari iOS 曾限 2.5MB，macOS Safari 17+ 升至 5MB；超限时抛出 QuotaExceededError，需 try...catch 捕获；无预检接口，须用 TextEncoder 估算 UTF-8 字节长度；大容量应选 IndexedDB 或 Cache API。
localStorage 在主流浏览器中的实际容量限制是多少
大多数现代浏览器对 localStorage 的单域名存储上限是 5MB（约 5,242,880 字节），但这个值不是绝对标准，而是由浏览器厂商自行实现的启发式限制。Chrome、Firefox、Edge 均按此档位执行；Safari 在 iOS 上曾长期限制为 2.5MB，macOS Safari 17+ 已提升至 5MB，但若用户开启“阻止所有 Cookie”或“防跟踪”策略，localStorage 可能被直接禁用或降为 0 容量。
超出 localStorage 容量时会触发什么错误
当调用 setItem() 写入数据超过限额，浏览器不会静默截断，而是抛出 QuotaExceededError DOM 异常（在部分旧版 Safari 中可能表现为 SyntaxError 或静默失败）。关键点在于：该错误只在写入瞬间抛出，不提供预检接口，也无法通过 localStorage.length 或 localStorage.key(0) 推算剩余空间。
- 必须用
try...catch包裹setItem()才能捕获异常 -
localStorage是同步阻塞操作，频繁写入大对象（如未压缩的 JSON）可能卡住主线程 - 字符串长度 ≠ 字节数：含中文、emoji 的字符串经 UTF-16 编码后，
.length返回的是字符数，而底层按字节计费；一个 emoji（如"?"）占 4 字节，但"?".length === 1
如何安全估算和管理 localStorage 使用量
没有浏览器 API 能直接读取已用字节数，只能靠手动估算。推荐做法是将待存数据先序列化为字符串，再用 new TextEncoder().encode(str).length 获取 UTF-8 字节长度（更贴近真实存储开销），并与 5MB 比较：
function getUtf8ByteLength(str) {
return new TextEncoder().encode(str).length;
}
<p>const data = JSON.stringify({ user: "张三", log: Array(1000).fill("x").join("") });
const bytes = getUtf8ByteLength(data);
if (bytes > 5 <em> 1024 </em> 1024) {
console.warn("超出 localStorage 容量限制");
} else {
try {
localStorage.setItem("cache", data);
} catch (e) {
if (e.name === "QuotaExceededError") {
console.error("本地存储已满");
}
}
}比 localStorage 更适合大容量存储的替代方案有哪些
如果需要存超过 5MB 的结构化数据，localStorage 就不该是首选。可按场景选择：
立即学习“前端免费学习笔记（深入）”；
- 临时缓存大量文本/JSON：改用
sessionStorage（同域同窗口内容量限制与localStorage相同，但关闭标签页即清空，适合中转） - 需持久化且容量大：使用
IndexedDB，支持数十 MB 甚至 GB 级存储（Chrome 对单数据库无硬上限，受磁盘空间约束） - 仅需存二进制文件（图片、音频）：结合
Blob+URL.createObjectURL()，或写入Cache API（Service Worker 环境下） - 服务端协同场景：优先将大块数据存在后端，前端只存 ID 和轻量元数据
真正容易被忽略的是：localStorage 的 5MB 是「每个协议+域名+端口」独立计算的，http://a.com 和 https://a.com 视为两个不同源，各自有 5MB；但同一页面内 iframe 加载的跨域子页面无法访问父页的 localStorage，哪怕域名相同——这是同源策略的刚性限制，不是容量问题。
