IndexedDB 的 objectStore 不能直接模糊搜索。原生仅支持精确匹配、范围查询和前缀匹配(需 IDBKeyRange.bound 配合 'uffff'),不支持 LIKE、通配符或正则;中间/结尾模糊须全量 JS 过滤,性能差;大小写敏感需手动处理;全文检索需服务端或降级方案。
不能。原生 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() 处理需在游标遍历中统一做,不可依赖索引自动转换虽然不能模糊,但合理建索引 + 游标边界控制,能高效支撑“以某字符串开头”的查询,这是最接近模糊搜索且性能可控的方案。
示例:对商品名字段 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" 本身因为 IndexedDB 没有这些概念。你看到的 FuzzyKeyword、WildcardQuery 都属于 TableStore、Elasticsearch 或 CSS 这类服务端搜索引擎的特性,和浏览器本地的 objectStore 完全无关。
混淆点常出现在文档误读:有人把 “TableStore 的多元索引支持模糊查询” 直接套用到 IndexedDB 上,结果发现 createIndex(..., { type: 'fuzzy' }) 报错 —— 因为 createIndex() 第三个参数只接受 { unique, multiEntry },不支持类型声明。
tiny-segmenter)预处理 + 多字段索引模拟localStorage 存 JSON + Array.filter()(仅限几百条以内)前缀搜索看似简单,但在多语言、用户输入不可控时,几个细节不处理就会出错:
" iphone")或全角空格(" iphone"):游标范围会失效,建议 .trim() 后再构造 IDBKeyRange
openCursor() 默认只读,如果边查边删/改,必须用 transaction(..., 'readwrite') 显式声明,否则报 InvalidStateError
onsuccess 里一次性 getAll(),用 cursor.continue() 分批处理,防止内存爆掉最麻烦的其实是“用户以为能搜中间内容”,而你只能告诉他们:前端本地数据库不支持,要么改需求,要么加服务端支持。