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()分批处理，防止内存爆掉
最麻烦的其实是“用户以为能搜中间内容”，而你只能告诉他们：前端本地数据库不支持，要么改需求，要么加服务端支持。
