如何使用 ObjectStore 索引功能在本地数据库实现模糊搜索

IndexedDB 的 objectStore 不能直接模糊搜索。原生仅支持精确匹配、范围查询和前缀匹配（需 IDBKeyRange.bound 配合 'uffff'），不支持 LIKE、通配符或正则；中间/结尾模糊须全量 JS 过滤，性能差；大小写敏感需手动处理；全文检索需服务端或降级方案。

IndexedDB 的 objectStore 能不能直接模糊搜索

不能。原生 objectStore 不支持 LIKE、通配符或正则匹配，只提供 get()、getAll()、openCursor() 和基于索引的 index.get() / index.openCursor() —— 后者仅支持精确值、范围（IDBKeyRange.lowerBound 等）和前缀匹配（需配合 IDBKeyRange.bound + 字符串比较逻辑），但不是真正的“模糊”。

常见错误现象：index.openCursor(IDBKeyRange.only('abc%')) 会查不到任何结果，因为 % 在 IndexedDB 中无特殊含义，它只是普通字符。

• 真正能用的“前缀搜索”必须靠 IDBKeyRange.lowerBound('abc', true) + 手动截断，且仅适用于开头一致的场景
• 中间或结尾模糊（如 *test* 或 *ing）必须全量读取后用 JS 字符串方法过滤，数据量大时卡顿明显
• 大小写敏感是默认行为，toLowerCase() 处理需在游标遍历中统一做，不可依赖索引自动转换

用 index.createIndex() 支持前缀搜索的关键配置

虽然不能模糊，但合理建索引 + 游标边界控制，能高效支撑“以某字符串开头”的查询，这是最接近模糊搜索且性能可控的方案。

示例：对商品名字段 name 建索引并查所有以 "iphone" 开头的商品：

objectStore.createIndex('namePrefix', 'name', { unique: false });// 查询时const lower = 'iphone';const upper = 'iphone' + 'uffff'; // Unicode 最大字符，确保覆盖所有以 iphone 开头的字符串const range = IDBKeyRange.bound(lower, upper, false, true);const request = index.openCursor(range);

• { unique: false } 必须显式指定，否则重复值会被静默丢弃
• 'uffff' 是关键技巧，不是随便选的占位符；它代表 UTF-16 编码最大值，能兜住所有合法字符串后缀
• 若字段含空格或特殊符号（如 "iPhone 15"），该方案仍有效，因字符串比较按字典序进行
• 不要用 IDBKeyRange.upperBound() 单独查，它不包含上界值，会导致漏掉 "iphone" 本身

为什么不用 full-text search 或 FuzzyKeyword 类型

因为 IndexedDB 没有这些概念。你看到的 FuzzyKeyword、WildcardQuery 都属于 TableStore、Elasticsearch 或 CSS 这类服务端搜索引擎的特性，和浏览器本地的 objectStore 完全无关。

混淆点常出现在文档误读：有人把 “TableStore 的多元索引支持模糊查询” 直接套用到 IndexedDB 上，结果发现 createIndex(..., { type: 'fuzzy' }) 报错 —— 因为 createIndex() 第三个参数只接受 { unique, multiEntry }，不支持类型声明。

• IndexedDB 的索引本质是 B+ 树结构，只加速等值和有序范围查找，不解析语义、不分词、不建倒排
• 想实现类似 Elasticsearch 的通配符能力，只能自己在 JS 层做字符串扫描，或引入轻量分词库（如 tiny-segmenter）预处理 + 多字段索引模拟
• 如果业务真需要全文检索，应考虑降级为服务端查询，或改用 localStorage 存 JSON + Array.filter()（仅限几百条以内）

真实项目中容易被忽略的边界情况

前缀搜索看似简单，但在多语言、用户输入不可控时，几个细节不处理就会出错：

• 用户输入空格开头（" iphone"）或全角空格（"　iphone"）：游标范围会失效，建议 .trim() 后再构造 IDBKeyRange
• 中文、日文等非 ASCII 字符排序依赖浏览器 ICU 实现，不同版本 Chrome 可能有细微差异，避免依赖“第 N 个字符等于某值”的逻辑
• openCursor() 默认只读，如果边查边删/改，必须用 transaction(..., 'readwrite') 显式声明，否则报 InvalidStateError
• 大数据量下，别在 onsuccess 里一次性 getAll()，用 cursor.continue() 分批处理，防止内存爆掉

最麻烦的其实是“用户以为能搜中间内容”，而你只能告诉他们：前端本地数据库不支持，要么改需求，要么加服务端支持。