先说结论：在鸿蒙 PC 的 Electron 应用里做本地搜索，如果你只盯着查询毫秒数，大概率会选错方案。
我等下会贴三段能直接跑的代码，分别是线性扫描、Fuse.js 和 SQLite FTS5。测下来，10000 条案例数据下，平均单次查询耗时大概是这个量级：
你看，Fuse.js 把 SQLite 按在地上摩擦。但结果你猜怎么着？我把项目里的实现换成了 SQLite。先别急着骂我标题党，听我把原因说完。
等一下，这里我漏说一个前提——我说的“本地搜索”不是指输入法那种即时提示，而是用户输入关键词后回车触发、需要返回排序结果列表的搜索。这个边界很重要，因为两种场景对延迟的容忍度完全不一样。输入法差 50ms 用户都能感知，但搜索结果页慢 10ms 基本无感。
测试环境也交代一下：华为 MateBook 鸿蒙 PC 工程机，CPU 是麒麟 9000S 桌面版，Electron 版本 33.x，Node 22。数据是我从公开渠道整理的一人公司案例库，每条记录包含标题、标签、正文摘要，平均 180 个汉字。测试前我先把其它进程杀干净，避免内存抖动干扰结果。
方案一，线性扫描。代码写起来最爽，一把梭：
// main/search/linear.tsinterface CaseItem { id: string; title: string; tags: string[]; content?: string;}export function linearSearch( list: CaseItem[], keyword: string): CaseItem[] { const lower = keyword.toLowerCase(); return list .filter(item => item.title.toLowerCase().includes(lower) || item.tags.some(t => t.toLowerCase().includes(lower)) ) .slice(0, 30);}
逻辑够直白吧？但这玩意儿有两个暗坑。第一，数据一多，主进程会被卡死。鸿蒙 PC 上 Electron 的主线程要是阻塞超过 200ms，窗口就会出现明显卡顿。我 5000 条数据时搜了一次，整个窗口冻结了将近 80ms，用户要是正在滚动列表，体验直接炸裂。第二，它只能做包含匹配，搜“鸿蒙”能命中“鸿蒙开发”，但搜“鸿蒙发”就凉了。你稍微想做点模糊匹配，代码就丑得不像样。
方案二，Fuse.js。这个库我挺喜欢的，轻量、API 友好，模糊搜索的效果也确实能打。
// main/search/fuse.tsimport Fuse from 'fuse.js';const fuseOptions = { keys: ['title', 'tags'], threshold: 0.35, includeScore: true, limit: 30,};export function createFuseIndex(list: CaseItem[]) { return new Fuse(list, fuseOptions);}export function fuseSearch( fuse: Fuse<CaseItem>, keyword: string): CaseItem[] { return fuse.search(keyword).map(r => r.item);}
初始化一次索引后，查询速度飞起。问题是，Fuse 会把整个索引结构挂在内存里。我测下来，10000 条案例数据大概占 18MB 左右。听上去不多？但 Electron 主进程的内存本来就被各种框架底层吃得很紧，鸿蒙 PC 上再给它加 18MB，我那个应用的启动速度肉眼可见地慢了一截。更难受的是，每次新增或删除数据，你都得重建索引。如果你的数据是离线下载、分批更新的，那这个重建过程会让用户感受到明显的卡顿。
还有个点很多人会忽略：Fuse.js 的索引构建本身也要时间。10000 条数据在我这台鸿蒙 PC 上初始化大概 220ms。也就是说，用户每次打开应用，都要先等 200 多毫秒把索引塞到内存里，搜索才能变快。如果数据还在增长，这个等待会越来越长。
方案三，SQLite FTS5。这是三种方案里最“重”的，但也是我最心动的。
// main/search/sqlite.tsimport Database from 'better-sqlite3';import path from 'path';import { app } from 'electron';let db: Database.Database;export function initSearchDB() { const dbPath = path.join(app.getPath('userData'), 'search.db'); db = new Database(dbPath); db.exec(` CREATE VIRTUAL TABLE IF NOT EXISTS cases USING fts5( id UNINDEXED, title, tags, content ); PRAGMA journal_mode = WAL; PRAGMA synchronous = NORMAL;`); return db;}export function upsertCases(items: CaseItem[]) { const insert = db.prepare(` INSERT OR REPLACE INTO cases (id, title, tags, content) VALUES (@id, @title, @tags, @content)`); const tagStringify = (tags: string[]) => tags.join(' '); const tx = db.transaction((rows: CaseItem[]) => { for (const row of rows) { insert.run({ id: row.id, title: row.title, tags: tagStringify(row.tags), content: row.content || '' }); } }); tx(items);}export function sqliteSearch(keyword: string): CaseItem[] { const stmt = db.prepare(` SELECT id, title, tags FROM cases WHERE cases MATCH ? ORDER BY rank LIMIT 30`); return stmt.all(`{name}: ${ms.toFixed(2)} ms/次`);}
跑之前记得把 better-sqlite3 在鸿蒙 PC 上重新编译一遍。我踩过的坑是，直接用 npm 装好的预编译二进制在鸿蒙定制内核上会报 NODE_MODULE_VERSION 不匹配，必须走 electron-rebuild。命令大概是：
npm run electron-rebuild -- -f -w better-sqlite3
如果你的 CI 环境还没有鸿蒙 PC 的交叉编译链，这一步能卡你半天。我建议先在真机上编一次，把产物提交到仓库，后面就不用每次都折腾。
那到底怎么选？我直接给判断标准，不按编号，想到哪儿说到哪儿。
如果你数据量不到 500 条，或者搜索需求就是简单的标题匹配，Fuse.js 更合适。启动快、代码少、效果柔和，用户输入体验也好。SQLite 这套方案，重就重在它给你留了后路。
如果你数据会增长，或者需要离线稳定、崩溃不丢数据，直接上 SQLite。别被那 10ms 的差距迷惑，真实用户根本感觉不出来。倒是应用 crash 后索引没了，用户下次打开要重新等 200ms 建索引，那才叫恼火。
顺带一提，我做的 App 雷达鸭（鸿蒙版已上架华为应用市场）里，那个案例搜索功能最终用的就是 SQLite FTS5 这套方案。
反正我现在做 Electron 跨端项目，本地搜索这块基本不会选 Fuse.js 做主存储方案了。毫秒数好看，但扛不住数据增长和异常场景。
你目前在 Electron 项目里用的是什么搜索方案？遇到过类似的选择纠结吗？
关于作者
老三，10 年以上软件开发经验，软件设计师、人工智能应用工程师。目前专注鸿蒙应用开发（ArkTS）北向开发与 Web 前端，也在折腾 AI 自动化。不定期在 CSDN 分享鸿蒙和 AI 方向的技术文章。
本文遵循 MIT 协议，转载请注明出处。
