如何用 IndexedDB 存储用户的搜索历史记录并实现支持前缀匹配的高效查询

如何利用 IndexedDB 高效存储与检索用户搜索历史：实现前缀匹配的最佳实践

想要构建一个响应迅速、精准匹配的搜索历史功能？关键在于利用 IndexedDB 的索引机制进行范围查询。通过为 searchText 建立索引并配合 IDBKeyRange.bound 方法，即可实现毫秒级的前缀匹配查询。相较于引入复杂的倒排索引或分词系统，这种方法更为轻量且高效。

为何应避免使用 includes 或正则进行全文扫描

许多开发者首先会考虑使用 searchText.includes('net') 来匹配“network”或“netlify”。虽然这种方法可行，但它存在明显缺陷：它会同时匹配到“internet”和“connect”，导致结果不精确。而正则表达式在 IndexedDB 中无法用于索引扫描，只能先获取全部数据再进行过滤。当面对数万条历史记录时，这种遍历操作将引发明显的性能卡顿。

真正的解决方案在于 IDBKeyRange.bound()。该方法对字符串索引天然支持字典序的范围查询，这正是实现高效前缀匹配的核心优势。

建立索引前必须进行文本规范化处理

前缀匹配对大小写和特殊字符非常敏感。若用户搜索“React”，而数据库中存储的是 "react" 或 "React!"，使用范围查询将无法命中。因此，数据写入前的统一预处理至关重要：

• 规范化输入：searchTerm = input.trim().toLowerCase().replace(/[^\w\s]/g, '')
• 存储设计：除了保存原始搜索词，额外添加一个专用于查询的字段，如 searchPrefix: searchTerm
• 创建索引：在该 searchPrefix 字段上建立**非唯一索引**：objectStore.createIndex('idx_prefix', 'searchPrefix', { unique: false })

这一步预处理是保障后续查询准确性与效率的基础。

使用 IDBKeyRange.bound 实现高性能前缀查询

核心思路是让数据库只扫描可能匹配的键值区间，而非获取所有数据后再过滤。例如，当用户输入“net”时，我们构造一个从 "net" 开始、到 "net\uFFFF" 结束的查询范围（\uFFFF 是 Unicode 最大码点，可确保覆盖所有以“net”开头的字符串）。

const range = IDBKeyRange.bound(query, query + '\uFFFF');
const index = objectStore.index('idx_prefix');
const cursorRequest = index.openCursor(range);

这样，游标只会遍历 "net"、"network"、"netlify" 等键，完全跳过无关记录。实测在数万条数据量下，查询响应时间可稳定在个位数毫秒级。

需要注意两个关键点：

• 若查询词 query 为空，IDBKeyRange.bound('', '\uFFFF') 将导致全表扫描，务必提前拦截：if (!query) return []。
• IndexedDB 的字符串比较基于码点（code point），而非本地化规则（locale）。这意味着中文、Emoji 均可正常处理，但无法自动处理特定语言规则（如德语“ß”对应“ss”）。

如何避免重复记录并维持时间顺序

搜索历史需避免重复条目（如用户连续输入“a”、“ab”、“abc”），并通常按时间倒序展示。推荐方案如下：

• 写入前查重：使用 index.get(query) 检查搜索词是否已存在。若存在，则通过 put() 更新其 updatedAt 时间戳，而非新增记录。
• 主键设计：可将主键的 keyPath 直接设为 'searchPrefix'。相同搜索词将自动去重，且在索引查询时能精确定位。
• 时间排序：在对象仓库中增加 timestamp: Date.now() 字段。获取前缀匹配的结果后，使用 Array.sort((a, b) => b.timestamp - a.timestamp) 在内存中排序。对于数据量不大的场景，这比建立复合索引更轻量。

最后，技术实现的高性能需与用户体验相结合。真正的流畅感往往依赖于细节优化：建议将查询逻辑包裹在 AbortController 中，并在用户输入停顿（例如200毫秒）后触发查询。缺少这个防抖优化，即使数据库查询再快，体验上仍会感到卡顿。