IndexedDB 查询性能取决于索引，高频字段须建索引；范围查询应使用 IDBKeyRange 而非 JS 过滤；缓存 key 需组合 URL、method 和脱敏 payload 并哈希；需主动按 expiresAt 清理过期数据。
查询前先确认索引是否到位
IndexedDB 的查询性能几乎完全取决于索引。没有索引的 get() 或 getAll() 会触发全表扫描，数据量稍大（比如超过 1 万条）就明显卡顿，甚至让 UI 线程无响应。高频查询字段必须建索引——比如按 status 筛选订单、按 category + updated_at 查列表、按 user_id 查个人数据。建索引时用 store.createIndex('status', 'status', { unique: false }) 即可，不需要设 multiEntry: true，除非你存的是数组且想对每个元素单独索引。
用 keyRange 做范围查询，别用 filter 循环
查“最近 7 天消息”或“状态为 pending 的前 50 条”，不要取全部再 JS 过滤。正确做法是：先确保 updated_at 或 status 字段有索引，然后用 IDBKeyRange.bound(start, end) 或 IDBKeyRange.only('pending') 构造范围，再调用 index.openCursor(range) 或 index.getAll(range)。这样数据库引擎直接定位到目标区间，毫秒级返回。例如：
const range = IDBKeyRange.bound(Date.now() - 7 * 24 * 60 * 60 * 1000, Date.now())const cursorReq = index.openCursor(range)
缓存键设计要兼顾唯一性与可预测性
做请求级缓存时，key 不建议只用 URL，因为带 query 参数或不同 body 的同一 URL 实际是不同资源。推荐组合生成：URL + method + JSON.stringify(payload 或 searchParams)，再哈希（如 MD5 或 sha-256）。这样相同请求总得到同一 key，便于命中；同时避免 key 过长影响索引效率（IndexedDB 对 key 长度无硬限制，但过长会影响 B+ 树性能）。注意：敏感参数（如 token、手机号）需脱敏后再参与 key 计算。
主动清理过期数据，别等配额告急
IndexedDB 不自动过期。缓存写入时应附带 expiresAt 字段（时间戳），并定期执行清理任务：用游标遍历索引（如按 expiresAt 建的索引），遇到过期项就 delete()。建议在页面空闲时（requestIdleCallback）或应用启动/切前台时触发，每次最多删 200 条，避免长时间阻塞。也可监听 navigator.storage.estimate()，当使用率超 80% 时降级清理策略（如优先删 temp_logs store，再删 api_cache 中 7 天前的数据）。
