HTML5 中不存在 GetAll 方法；实际可用的是 IndexedDB 的 getAll()（高效但有内存限制）和 localStorage/sessionStorage 的手动遍历（同步阻塞，性能差），推荐用 IndexedDB 游标分页或 Cache API 的 matchAll() 替代。
HTML5 标准中并不存在名为 GetAll 的内置方法，因此所谓“GetAll 方法一次性检索所有存储对象的性能分析”属于概念性误用或混淆。实际开发中常被提及的类似操作，通常指向 IndexedDB 的 getAll() 方法（如 objectStore.getAll()），或对 localStorage/sessionStorage 的手动遍历模拟。下面从真实可用的 API 出发，分析其性能表现与适用边界。
IndexedDB 的 getAll() 方法：高效但有前提
getAll() 是 IDBObjectStore 和 IDBIndex 接口提供的异步方法，用于批量读取匹配项。它比循环调用 get() 更高效，原因在于：
- 底层数据库引擎可优化为单次 B-Tree 扫描，减少 I/O 次数和事件循环开销；
- 避免多次 Promise 创建与调度，降低 JS 引擎微任务队列压力；
- 返回结果为完整数组，便于后续处理，无需手动拼接。
但需注意：getAll() 不支持条件过滤（如 WHERE 子句），若需按范围查询，应使用 openCursor() 或带 keyRange 的 getAll(range)；且当数据量极大（如 >10 万条、单条平均 >10 KB）时，可能触发内存峰值甚至 OOM，浏览器会限制其响应大小（Chrome 当前默认上限约 2GB 内存占用，但实际建议控制在几 MB 级别）。
localStorage/sessionStorage 没有 GetAll，只能遍历
这两个 Web Storage API 仅提供 getItem(key)、setItem(key, value) 和 key(index) 等基础方法，**不提供批量获取接口**。若想“一次性获取所有键值对”，必须手动遍历：
- 先用
localStorage.length获取总数； - 再用
localStorage.key(i)取出每个键； - 最后逐个
getItem(key)读取值。
该方式本质是同步阻塞操作，在主 UI 线程执行，若存储项达数百个、单值较大（如 JSON 字符串超 100KB），会导致明显卡顿。实测显示：1000 个 1KB 的键值对，遍历耗时约 8–15ms（取决于设备），而 10000 个则可能超过 100ms，影响帧率。不推荐在关键路径（如页面初始化）中全量读取。
实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。
性能优化的关键实践
真正影响性能的不是“是否叫 GetAll”，而是数据规模、访问模式与实现方式：
- 优先使用 IndexedDB +
getAll()替代 localStorage 全量遍历，尤其在需要结构化查询时； - 对大数据集，改用游标（
openCursor()）分页读取，配合yield或requestIdleCallback防止阻塞； - 为 IndexedDB 添加合适索引，使
getAll(keyRange)能走索引扫描而非全表扫描； - localStorage 仅用于轻量、高频、小体积状态（如用户主题、折叠状态），避免存日志、缓存 HTML 或大型配置对象。
替代方案：Cache API 或 Service Worker 缓存更适配资源批量操作
若目标是批量读取网络资源（如图片、脚本、JSON 数据），Cache API 提供了真正的 keys() 和 matchAll() 方法，支持正则匹配、请求参数过滤，并基于 HTTP 缓存语义设计，性能稳定且不阻塞主线程。例如：
const cache = await caches.open('my-cache');
const requests = await cache.keys(); // 获取所有缓存请求 URL 列表
const responses = await cache.matchAll(); // 批量获取响应对象这类 API 才更接近“一次性检索所有存储对象”的原始意图，且具备明确的性能保障机制。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
