現(xiàn)及踩坑指南)
今天是“30天挑戰(zhàn)”的第11天整個(gè)項(xiàng)目剛好走完三分之一。先交代一下背景我在做的是一個(gè)本地優(yōu)先的 Markdown 知識(shí)管理工具 DayNotes要求數(shù)據(jù)完全離線、啟動(dòng)速度快、折騰成本低。前 10 天已經(jīng)完成了文檔解析、編輯器、標(biāo)簽體系和列表頁(yè)今天集中攻一個(gè)繞不過(guò)去的功能——全文搜索。如果你也在做類似的知識(shí)庫(kù)、筆記工具或者本地文檔管理應(yīng)用這一篇應(yīng)該能幫你少走不少?gòu)澛酚绕涫巧婕暗街形姆衷~和桌面端性能的部分我會(huì)把踩過(guò)的坑和排查過(guò)程原原本本寫出來(lái)。1. 第11天的進(jìn)度線從“正則匹配”到“全文索引”每天開(kāi)工前我都會(huì)花 10 分鐘把當(dāng)天要做的功能拆成小塊寫在項(xiàng)目的 TODO 里。今天的標(biāo)簽是“搜索模塊”乍一聽(tīng)范圍很大真正拆開(kāi)其實(shí)就三塊索引怎么建、查詢?cè)趺磮?zhí)行、結(jié)果怎么展示。想清楚再動(dòng)手寫代碼的速度會(huì)快很多。1.1 前10天做了什么為什么今天才開(kāi)始做搜索DayNotes 前 10 天的功能比較基礎(chǔ)本地目錄掃描、Markdown 文件解析、編輯器支持即時(shí)預(yù)覽、標(biāo)簽體系、文檔列表的排序和篩選。在最初的設(shè)計(jì)里我其實(shí)沒(méi)有考慮索引搜索直接用最簡(jiǎn)單粗暴的辦法——遞歸遍歷目錄對(duì)每個(gè)文件的文本內(nèi)容做正則匹配。剛開(kāi)始內(nèi)容少的時(shí)候這個(gè)方法一點(diǎn)問(wèn)題沒(méi)有。幾十篇文檔遍歷一遍也就幾十毫秒用戶根本感覺(jué)不出來(lái)。直到第 10 天我把手上攢了兩年的一千多篇 Markdown 筆記全部導(dǎo)進(jìn)去之后情況急轉(zhuǎn)直下每次搜索要遍歷一千多個(gè)文件全部讀一遍再匹配慢的時(shí)候要兩三秒而且界面直接卡住因?yàn)樽x取和正則匹配都是在主線程做的。正是在這個(gè)節(jié)點(diǎn)我才意識(shí)到不引入真正的全文索引后面沒(méi)法用了。這算是一個(gè)挺典型的教訓(xùn)前期做原型可以偷懶但當(dāng)你明顯感覺(jué)到“內(nèi)容量上來(lái)之后體驗(yàn)崩壞”的瞬間就是該上正經(jīng)方案的時(shí)候了。DayNotes 的整體存儲(chǔ)層早就分開(kāi)了元數(shù)據(jù)在 SQLite正文按文件路徑讀取所以今天加索引不需要?jiǎng)拥讓咏Y(jié)構(gòu)這讓工作量小了不少。1.2 技術(shù)選型為什么最終選了SQLite FTS5桌面端做全文搜索可選方案其實(shí)不少。我把當(dāng)時(shí)認(rèn)真考慮過(guò)的幾個(gè)方案列了個(gè)表方便對(duì)比方案優(yōu)點(diǎn)缺點(diǎn)結(jié)論Elasticsearch功能強(qiáng)、生態(tài)成熟要裝 Java 環(huán)境、起服務(wù)、占內(nèi)存對(duì)單機(jī)離線工具太重放棄Meilisearch / Typesense開(kāi)箱即用、搜索體驗(yàn)好需要額外進(jìn)程部署和升級(jí)成本高放棄SQLite LIKE 通配查詢實(shí)現(xiàn)簡(jiǎn)單沒(méi)有分詞、不能排序、一千篇就卡放棄SQLite FTS5 虛擬表內(nèi)嵌在庫(kù)里、零額外服務(wù)、支持 BM25 排序中文分詞要自己處理采用最終選 SQLite FTS5 是綜合考慮了離線、單機(jī)、輕量這三點(diǎn)。DayNotes 的元數(shù)據(jù)本來(lái)就在 SQLite 里FTS5 虛擬表可以直接建在同一份數(shù)據(jù)庫(kù)文件中不需要額外維護(hù)一個(gè)索引服務(wù)也不引入新的運(yùn)行時(shí)依賴。對(duì)于“本地優(yōu)先”的工具來(lái)說(shuō)這個(gè)方案是復(fù)雜度最低、可控性最高的。還有一個(gè)容易被忽略的好處FTS5 索引跟隨數(shù)據(jù)庫(kù)文件走備份、遷移、同步都統(tǒng)一了。如果將來(lái)要支持多設(shè)備同步索引也可以跟著數(shù)據(jù)庫(kù)一起處理不需要擔(dān)心本地文件和服務(wù)狀態(tài)不一致。這一點(diǎn)在我這種跨平臺(tái)小工具里非常重要。2. SQLite FTS5 做中文全文搜索三個(gè)必須繞開(kāi)的坑FTS5 本身很成熟但它是為英文環(huán)境設(shè)計(jì)的默認(rèn)行為對(duì)中文特別不友好。這幾個(gè)坑我基本是逐個(gè)踩過(guò)來(lái)的每一個(gè)都會(huì)導(dǎo)致“搜索結(jié)果完全不可用”。2.1 unicode61分詞器對(duì)中文等于沒(méi)有分詞FTS5 默認(rèn)的分詞器是 unicode61它按照 Unicode 字符類型做切分。英文、數(shù)字這類能很好處理空格和標(biāo)點(diǎn)作為分隔符每個(gè)單詞建立索引。但中文沒(méi)有空格整段文字在 unicode61 眼里就是一個(gè)連續(xù)的“詞語(yǔ)”所以它只能把整句當(dāng)成一個(gè) token。這會(huì)導(dǎo)致什么后果如果你的筆記里有“知識(shí)筆記軟件”這個(gè)詞你搜索“筆記”FTS5 是匹配不到的因?yàn)樗⑺饕淖钚挝皇钦湓挾皇恰爸R(shí)”“筆記”“軟件”這些詞。我當(dāng)時(shí)第一次跑通搜索輸入“筆記”結(jié)果返回空一度以為自己建表語(yǔ)句寫錯(cuò)了。更麻煩的是FTS5 還默認(rèn)把超長(zhǎng) token 給截?cái)嗄J(rèn)情況下每個(gè)分詞單元的索引上限是 10 個(gè)字符。中文一句話遠(yuǎn)超過(guò)這個(gè)長(zhǎng)度后面的內(nèi)容根本不會(huì)進(jìn)索引也就是說(shuō)搜索“一篇長(zhǎng)文中后半段的某個(gè)詞”永遠(yuǎn)搜不到。要解決這個(gè)問(wèn)題就得繞開(kāi)默認(rèn)分詞器在寫入索引之前自己做分詞把分詞結(jié)果按約定格式填進(jìn)去。這也是我換到 jieba 的根本原因。2.2 用 jieba 預(yù)分詞索引側(cè)和查詢側(cè)要配合確定用 jieba 之后一個(gè)比較自然的思路是寫入時(shí)先把標(biāo)題和正文分詞用空格把詞拼起來(lái)存到 FTS5 表里查詢時(shí)也對(duì)用戶輸入分詞再拼成查詢語(yǔ)句。建表語(yǔ)句我改成了這樣CREATE VIRTUAL TABLE IF NOT EXISTS doc_search USING fts5( doc_id UNINDEXED, title, content_seg, content_raw, tokenize unicode61 );這里content_seg存的是分詞后的文本content_raw存原始正文用來(lái)在結(jié)果列表里做上下文摘要。查詢時(shí)配合 jieba 做同樣的分詞處理import jieba def build_query(text): words [w.strip() for w in jieba.cut(text) if w.strip()] return OR .join(f{w} for w in words)這里有一個(gè)很關(guān)鍵也很容易寫錯(cuò)的細(xì)節(jié)查詢時(shí)拼出來(lái)的每個(gè)詞都要加雙引號(hào)否則 FTS5 會(huì)把用戶輸入當(dāng)成一個(gè)完整的短語(yǔ)去匹配分好詞也沒(méi)用。我當(dāng)時(shí)在這個(gè)地方吃了虧——索引側(cè)分詞做好了查詢側(cè)忘了給詞加引號(hào)結(jié)果搜“筆記軟件”時(shí)命中的是完整的“筆記軟件”短語(yǔ)而不是“筆記”和“軟件”兩個(gè)詞的任意匹配。另外jieba 的默認(rèn)詞庫(kù)對(duì)通用中文處理得不錯(cuò)但對(duì)專業(yè)領(lǐng)域術(shù)語(yǔ)識(shí)別很差。我的筆記里有大量技術(shù)名詞比如“Rust”“Tauri”“unmount”這類中英混合詞默認(rèn)詞典經(jīng)常切得稀碎。解決辦法是維護(hù)一個(gè)自定義詞典文件把高頻術(shù)語(yǔ)加進(jìn)去。2.3 索引同步機(jī)制增刪改怎么保持一致性建立一個(gè)索引只是第一步真正讓人頭疼的是后續(xù)的持續(xù)同步。文檔會(huì)新增、修改、刪除索引如果不跟著變搜索就變成垃圾數(shù)據(jù)展示。我在設(shè)計(jì)上采用了一個(gè)非常樸素的方案在應(yīng)用層做同步不搞數(shù)據(jù)庫(kù)觸發(fā)器。文檔保存的時(shí)候順帶調(diào)用一個(gè)sync_doc_to_index函數(shù)把該文檔從索引里刪掉再重新插入。流程拆開(kāi)看大概是這么幾步文檔保存時(shí)讀取最新的標(biāo)題和正文用 jieba 對(duì)標(biāo)題和正文做分詞先從doc_search里刪除該doc_id的所有舊記錄再插入一條新記錄。這里要注意FTS5 虛擬表沒(méi)有主鍵約束如果用INSERT OR REPLACE去按doc_id覆蓋會(huì)因?yàn)閐oc_id不是真正的主鍵而插入重復(fù)行。所以邏輯上必須是“先刪后插”不能偷懶。剛一開(kāi)始我圖省事只在文檔保存時(shí)同步?jīng)]有處理批量導(dǎo)入的場(chǎng)景。結(jié)果第 10 天我導(dǎo)入一千多篇文檔導(dǎo)入完成后索引是空的因?yàn)榕繉懭肼窂綁焊鶝](méi)有調(diào)用同步函數(shù)。后來(lái)我在導(dǎo)入流程的末尾統(tǒng)一執(zhí)行了一次全量重建索引# 先刪除整個(gè)虛擬表 DROP TABLE IF EXISTS doc_search; # 再建表 # 然后從 docs 表里重新讀取全部分詞寫入全量重建索引其實(shí)沒(méi)有想象中那么慢一千多篇 Markdown 文檔全部重新分詞再寫入在我的筆記本上大概也就是兩秒多。所以日常增量靠保存時(shí)同步批量操作后做一次重建索引一致性的問(wèn)題就基本解決了。3. 本輪踩坑實(shí)錄從“搜不出”到“排序不對(duì)”的完整排查鏈路這一節(jié)我要完整記錄今天遇到的三個(gè)問(wèn)題的排查過(guò)程。之所以寫這么細(xì)是因?yàn)檫@些問(wèn)題的表象和根因離得很遠(yuǎn)光看報(bào)錯(cuò)信息完全無(wú)從下手必須自己一步步推。3.1 搜索“筆記”搜不出“知識(shí)筆記”分詞器的鍋問(wèn)題出現(xiàn)得非常突然。第一輪功能做完之后我輸入“筆記”測(cè)試結(jié)果返回零條。數(shù)據(jù)庫(kù)里明明有十幾篇標(biāo)題帶“筆記”的文檔為什么搜不到排查第一步是驗(yàn)證原始數(shù)據(jù)有沒(méi)有進(jìn)索引。我直接打開(kāi) SQLite查doc_search表里有多少條記錄確認(rèn)數(shù)據(jù)確實(shí)寫入了。第二步是看匹配行為單獨(dú)執(zhí)行SELECT doc_id, title FROM doc_search WHERE doc_search MATCH 筆記;返回空。換一個(gè)查法SELECT doc_id, title FROM doc_search WHERE doc_search MATCH 知識(shí)筆記;居然能查到。這一步基本確認(rèn)了問(wèn)題出在分詞索引里根本沒(méi)有“筆記”這個(gè) token只有“知識(shí)筆記”這種整句 token。原因就是前面說(shuō)的 unicode61 分詞器不切分中文。排查到這里方向已經(jīng)很清楚了不是數(shù)據(jù)問(wèn)題不是查詢語(yǔ)法問(wèn)題是分詞策略問(wèn)題。解決方式不做展開(kāi)——換成 jieba 預(yù)分詞之后重建索引再搜“筆記”能正常命中了。一個(gè)容易忽略的點(diǎn)是重建索引之后舊 token 還殘留在虛擬表里所以排查時(shí)一定記住先 DROP 再重建。3.2 輸入一個(gè)關(guān)鍵字CPU就飆升IPC通信和全表掃描分詞問(wèn)題解決后搜索的核心功能能用了但隨之而來(lái)的是性能問(wèn)題。我在輸入框里打了三個(gè)字應(yīng)用窗口就出現(xiàn)明顯的卡頓系統(tǒng)監(jiān)視器一看CPU 占用直接頂滿。一開(kāi)始我以為是 FTS5 索引查詢本身慢后來(lái)仔細(xì)一想FTS5 對(duì)一千多篇文檔的索引查詢應(yīng)該是毫秒級(jí)不可能是瓶頸。于是我把排查重點(diǎn)放在調(diào)用鏈路上。DayNotes 用的框架里渲染進(jìn)程和主進(jìn)程之間通過(guò) IPC 通信。我的搜索邏輯在主進(jìn)程里執(zhí)行每次輸入框有內(nèi)容變化渲染進(jìn)程就發(fā)一次 IPC 請(qǐng)求。關(guān)鍵在于我監(jiān)聽(tīng)的是input事件每敲一個(gè)字符都會(huì)觸發(fā)一次請(qǐng)求。如果一句搜索詞有五個(gè)字輸入過(guò)程中就發(fā)了五次請(qǐng)求而且主進(jìn)程每次都要連接數(shù)據(jù)庫(kù)、執(zhí)行查詢、把結(jié)果序列化回傳。還有一個(gè)隱藏的性能殺手我在主進(jìn)程的搜索函數(shù)里拿到搜索結(jié)果后會(huì)讀取命中文檔的完整內(nèi)容來(lái)做上下文摘要。一千多篇文檔匹配到幾十篇每篇都要讀文件、截取摘要這個(gè)操作比索引查詢本身慢得多。解決分兩層渲染進(jìn)程側(cè)加防抖用戶停止輸入 300ms 后才發(fā)請(qǐng)求主進(jìn)程側(cè)只查結(jié)果的前 50 條并且摘要直接從 FTS5 表里存好的content_raw字段截取不額外讀磁盤文件。防抖代碼很簡(jiǎn)單大概是這樣的let timer; inputElement.addEventListener(input, () { clearTimeout(timer); timer setTimeout(() { search(inputElement.value); }, 300); });加完之后即使連續(xù)輸入整句話實(shí)際查詢也只觸發(fā)一次CPU 占用基本可以忽略。3.3 標(biāo)題命中的結(jié)果排到了正文后面rank排序修正功能能跑、性能也上去了第三個(gè)問(wèn)題浮出水面搜索結(jié)果排序不對(duì)。按常識(shí)標(biāo)題里包含關(guān)鍵詞的文章優(yōu)先級(jí)應(yīng)該高于正文里碰巧出現(xiàn)一次關(guān)鍵詞的文章。但實(shí)際結(jié)果恰恰相反正文提到的排在前面標(biāo)題命中的卻排到了后面。FTS5 默認(rèn)的排序依據(jù)是 BM25 算法它會(huì)綜合考慮詞頻、文檔長(zhǎng)度等因素打分。這個(gè)打分本身沒(méi)問(wèn)題但它完全不理解“標(biāo)題命中”這件事在業(yè)務(wù)上的重要性。對(duì)于知識(shí)管理工具來(lái)說(shuō)標(biāo)題命中往往意味著這篇文章就是講這個(gè)主題的正文命中可能只是順帶提到。修正方式是給排序加權(quán)重。FTS5 對(duì)每一行會(huì)算出一個(gè)rank值rank越小越靠前。我在ORDER BY里人為加上一個(gè)判斷如果標(biāo)題里包含搜索詞就給這行減一個(gè)固定值讓它排上去SELECT doc_id, title, rank FROM doc_search WHERE doc_search MATCH ? ORDER BY rank CASE WHEN title LIKE % || ? || % THEN -20 ELSE 0 END LIMIT 50;這種加權(quán)方式雖然粗暴但對(duì)于個(gè)人工具完全夠用。再進(jìn)一步還可以給標(biāo)簽命中更高的權(quán)重這個(gè)今天沒(méi)做列進(jìn)了后面的計(jì)劃里。排查過(guò)程中有一個(gè)值得記錄的細(xì)節(jié)很多人會(huì)直接把搜索詞拼進(jìn) SQL 里這在本地單機(jī)工具里問(wèn)題不大但一旦數(shù)據(jù)源來(lái)自第三方就有 SQL 注入風(fēng)險(xiǎn)。FTS5 的正規(guī)寫法是用MATCH ?傳參我全程都用占位符這個(gè)習(xí)慣值得長(zhǎng)期保持。4. 搜索框背后容易被忽略的交互與性能細(xì)節(jié)搜索模塊的核心打通之后剩下的工作主要圍繞“好用”展開(kāi)。功能能跑只是起點(diǎn)真正決定用戶感受的往往是那些技術(shù)棧之外的小細(xì)節(jié)。4.1 300ms防抖加過(guò)期請(qǐng)求丟棄防抖解決了“打字過(guò)程中反復(fù)請(qǐng)求”的問(wèn)題但還有一個(gè)并發(fā)場(chǎng)景沒(méi)處理如果用戶在防抖生效之前快速按了回車上一個(gè)請(qǐng)求還沒(méi)返回新的請(qǐng)求就發(fā)出去了。這種情況下兩個(gè)請(qǐng)求的返回順序是不確定的先發(fā)出的請(qǐng)求后返回就會(huì)把較新的結(jié)果覆蓋掉造成搜索結(jié)果落后于輸入框內(nèi)容。解決辦法是在渲染進(jìn)程維護(hù)一個(gè)自增的請(qǐng)求編號(hào)let requestId 0; async function search(keyword) { const currentId requestId; const results await window.api.search(keyword); if (currentId ! requestId) return; // 過(guò)期結(jié)果直接丟棄 renderResults(results); }這個(gè)模式在很多場(chǎng)景下都通用尤其是桌面端和前端交互。思路很簡(jiǎn)單每次都把請(qǐng)求編號(hào)遞增哪個(gè)結(jié)果回來(lái)時(shí)發(fā)現(xiàn)自己已經(jīng)不是最新編號(hào)了就放棄渲染。4.2 搜索高亮的正確姿勢(shì)先轉(zhuǎn)義再渲染搜索結(jié)果列表里匹配的關(guān)鍵詞需要高亮否則用戶看不出為什么這篇被搜出來(lái)了。我一開(kāi)始直接用正則替換原始正文把命中詞替換成mark命中詞/mark然后塞進(jìn)渲染層。寫完一測(cè)發(fā)現(xiàn)一個(gè)嚴(yán)重安全漏洞——如果正文本身包含 HTML 標(biāo)簽比如一篇講前端開(kāi)發(fā)的筆記里寫了div這個(gè)標(biāo)簽會(huì)被渲染層當(dāng)成真正的 DOM 執(zhí)行。正確順序必須是先把原始文本做 HTML 轉(zhuǎn)義再做高亮替換。比如function escapeHtml(text) { return text .replace(//g, amp;) .replace(//g, lt;) .replace(//g, gt;) .replace(//g, quot;) .replace(//g, #039;); } function highlight(text, terms) { const safe escapeHtml(text); const escapedTerms terms.map(escapeHtml); let result safe; for (const term of escapedTerms) { result result.replaceAll(term, (match) mark${match}/mark); } return result; }先轉(zhuǎn)義再替換既能保證高亮生效又不會(huì)讓原始 HTML 破壞頁(yè)面結(jié)構(gòu)。順便一提replaceAll里面用函數(shù)作為參數(shù)是為了避免$這種特殊替換變量的坑寫的時(shí)候容易被忽略。4.3 空態(tài)、快捷鍵和索引狀態(tài)感知細(xì)節(jié)上我還做了幾個(gè)不起眼但價(jià)值很大的功能。搜索無(wú)結(jié)果時(shí)的空態(tài)我一開(kāi)始只顯示了“沒(méi)有找到匹配內(nèi)容”一行字后來(lái)發(fā)現(xiàn)這樣很容易讓用戶陷入死胡同。現(xiàn)在空態(tài)里會(huì)提示嘗試縮短關(guān)鍵詞、檢查是否有錯(cuò)別字、或者去設(shè)置里重建索引。實(shí)際使用中很多“搜不到”的問(wèn)題根源是索引沒(méi)有跟上給出重建索引的引導(dǎo)能省掉很多用戶困惑。全局快捷鍵CtrlK聚焦搜索框這已經(jīng)是這類工具的標(biāo)配了我之前的編輯器里其實(shí)已經(jīng)有了今天只是把觸發(fā)邏輯統(tǒng)一到搜索組件上。還有一個(gè)小細(xì)節(jié)搜索框里輸入全角空格或者只有空格的字符串時(shí)不會(huì)發(fā)起搜索請(qǐng)求避免又一次無(wú)意義的 IPC。索引狀態(tài)感知也是一個(gè)容易漏掉的功能。我在設(shè)置頁(yè)里增加了一個(gè)“索引信息”面板顯示當(dāng)前索引了多少文檔、最近一次重建時(shí)間、自建詞典的詞條數(shù)。這看起來(lái)像是開(kāi)發(fā)者接口但對(duì)個(gè)人工具來(lái)說(shuō)它是排查“為什么搜不到”的第一入口。5. 30天挑戰(zhàn)過(guò)半我重新思考“搜索”這件事今天是第 11 天項(xiàng)目已過(guò)三分之一正好借這個(gè)機(jī)會(huì)做一次階段性復(fù)盤。我發(fā)現(xiàn)做知識(shí)管理工具搜索不僅僅是一個(gè)功能模塊它在很大程度上決定了用戶對(duì)這個(gè)工具的信任感。5.1 這11天最大的教訓(xùn)接口預(yù)留與過(guò)早優(yōu)化回頭看我前 10 天的代碼最慶幸的是當(dāng)初做存儲(chǔ)層的時(shí)候把“元數(shù)據(jù)”和“正文內(nèi)容”明確分開(kāi)了。文檔表只存標(biāo)題、路徑、標(biāo)簽、創(chuàng)建時(shí)間這些結(jié)構(gòu)化數(shù)據(jù)正文通過(guò)文件路徑按需讀取。這個(gè)設(shè)計(jì)當(dāng)時(shí)只是出于“Markdown 文件本來(lái)就應(yīng)該直接存在磁盤上”的直覺(jué)沒(méi)想到今天加搜索引擎時(shí)幾乎不用改動(dòng)原來(lái)的數(shù)據(jù)層直接在旁邊多建一張 FTS5 虛擬表就接上了。這一點(diǎn)其實(shí)比“一開(kāi)始就設(shè)計(jì)好搜索功能”更重要——前期搜索需求不明確如果強(qiáng)行一開(kāi)始就設(shè)計(jì)索引結(jié)構(gòu)大概率會(huì)根據(jù)錯(cuò)誤的假設(shè)做出過(guò)度設(shè)計(jì)。更合理的做法是保證層與層之間的邊界清晰給未來(lái)的功能留出插入位置而不是提前把所有擴(kuò)展點(diǎn)都實(shí)現(xiàn)。與之相對(duì)的另一個(gè)極端是過(guò)早優(yōu)化。我最初沒(méi)加搜索原因就是覺(jué)得“內(nèi)容少用正則也行”。事實(shí)證明這個(gè)決定是對(duì)的正是因?yàn)閮?nèi)容量到了臨界點(diǎn)、體驗(yàn)真實(shí)惡化我才理解了為什么需要索引而不是憑空想象出一個(gè)性能問(wèn)題。過(guò)早引入 ES 或者重型的搜索服務(wù)只會(huì)讓項(xiàng)目陷入維護(hù)泥潭。5.2 明天的計(jì)劃可配置的詞庫(kù)和重建索引入口雖然今天的搜索功能已經(jīng)能正常使用了但距離“順手”還有一段距離。我整理了幾個(gè)必須要做的東西設(shè)置頁(yè)增加“重建索引”按鈕配合進(jìn)度提示解決用戶遇到搜索異常時(shí)的自救途徑自建詞典的可視化管理方便把常用術(shù)語(yǔ)直接加進(jìn)詞庫(kù)不用改配置文件重啟標(biāo)簽權(quán)重加分讓標(biāo)簽命中排在標(biāo)題命中前面增強(qiáng)檢索業(yè)務(wù)語(yǔ)義搜索歷史記錄把最近的搜索詞存在本地方便重復(fù)查找。這些功能都不復(fù)雜難點(diǎn)在于接口怎么設(shè)計(jì)得順滑。比如重建索引進(jìn)度提示如果索引量少根本不需要進(jìn)度條但如果文檔量上千就必須給用戶一個(gè)明確的“在做什么”的狀態(tài)反饋避免誤以為卡死。寫到這里我想多說(shuō)一句個(gè)人體會(huì)。做本地優(yōu)先的工具最大的幸福感其實(shí)來(lái)自“它能自己持續(xù)變得好用”這件事。前 10 天寫編輯器、寫標(biāo)簽系統(tǒng)是給自己造器皿這一天的搜索功能做出來(lái)之后我每天記錄筆記時(shí)終于敢往里面堆量了因?yàn)槲抑馈刚业玫健惯@個(gè)底線已經(jīng)被守住了。30 天的項(xiàng)目還在繼續(xù)明天繼續(xù)解決新問(wèn)題。 基于SQLite FTS5的中文全文搜索實(shí)現(xiàn)及踩坑指南
今天是“30天挑戰(zhàn)”的第11天整個(gè)項(xiàng)目剛好走完三分之一。先交代一下背景我在做的是一個(gè)本地優(yōu)先的 Markdown 知識(shí)管理工具 DayNotes要求數(shù)據(jù)完全離線、啟動(dòng)速度快、折騰成本低。前 10 天已經(jīng)完成了文檔解析、編輯器、標(biāo)簽體系和列表頁(yè)今天集中攻一個(gè)繞不過(guò)去的功能——全文搜索。如果你也在做類似的知識(shí)庫(kù)、筆記工具或者本地文檔管理應(yīng)用這一篇應(yīng)該能幫你少走不少?gòu)澛酚绕涫巧婕暗街形姆衷~和桌面端性能的部分我會(huì)把踩過(guò)的坑和排查過(guò)程原原本本寫出來(lái)。1. 第11天的進(jìn)度線從“正則匹配”到“全文索引”每天開(kāi)工前我都會(huì)花 10 分鐘把當(dāng)天要做的功能拆成小塊寫在項(xiàng)目的 TODO 里。今天的標(biāo)簽是“搜索模塊”乍一聽(tīng)范圍很大真正拆開(kāi)其實(shí)就三塊索引怎么建、查詢?cè)趺磮?zhí)行、結(jié)果怎么展示。想清楚再動(dòng)手寫代碼的速度會(huì)快很多。1.1 前10天做了什么為什么今天才開(kāi)始做搜索DayNotes 前 10 天的功能比較基礎(chǔ)本地目錄掃描、Markdown 文件解析、編輯器支持即時(shí)預(yù)覽、標(biāo)簽體系、文檔列表的排序和篩選。在最初的設(shè)計(jì)里我其實(shí)沒(méi)有考慮索引搜索直接用最簡(jiǎn)單粗暴的辦法——遞歸遍歷目錄對(duì)每個(gè)文件的文本內(nèi)容做正則匹配。剛開(kāi)始內(nèi)容少的時(shí)候這個(gè)方法一點(diǎn)問(wèn)題沒(méi)有。幾十篇文檔遍歷一遍也就幾十毫秒用戶根本感覺(jué)不出來(lái)。直到第 10 天我把手上攢了兩年的一千多篇 Markdown 筆記全部導(dǎo)進(jìn)去之后情況急轉(zhuǎn)直下每次搜索要遍歷一千多個(gè)文件全部讀一遍再匹配慢的時(shí)候要兩三秒而且界面直接卡住因?yàn)樽x取和正則匹配都是在主線程做的。正是在這個(gè)節(jié)點(diǎn)我才意識(shí)到不引入真正的全文索引后面沒(méi)法用了。這算是一個(gè)挺典型的教訓(xùn)前期做原型可以偷懶但當(dāng)你明顯感覺(jué)到“內(nèi)容量上來(lái)之后體驗(yàn)崩壞”的瞬間就是該上正經(jīng)方案的時(shí)候了。DayNotes 的整體存儲(chǔ)層早就分開(kāi)了元數(shù)據(jù)在 SQLite正文按文件路徑讀取所以今天加索引不需要?jiǎng)拥讓咏Y(jié)構(gòu)這讓工作量小了不少。1.2 技術(shù)選型為什么最終選了SQLite FTS5桌面端做全文搜索可選方案其實(shí)不少。我把當(dāng)時(shí)認(rèn)真考慮過(guò)的幾個(gè)方案列了個(gè)表方便對(duì)比方案優(yōu)點(diǎn)缺點(diǎn)結(jié)論Elasticsearch功能強(qiáng)、生態(tài)成熟要裝 Java 環(huán)境、起服務(wù)、占內(nèi)存對(duì)單機(jī)離線工具太重放棄Meilisearch / Typesense開(kāi)箱即用、搜索體驗(yàn)好需要額外進(jìn)程部署和升級(jí)成本高放棄SQLite LIKE 通配查詢實(shí)現(xiàn)簡(jiǎn)單沒(méi)有分詞、不能排序、一千篇就卡放棄SQLite FTS5 虛擬表內(nèi)嵌在庫(kù)里、零額外服務(wù)、支持 BM25 排序中文分詞要自己處理采用最終選 SQLite FTS5 是綜合考慮了離線、單機(jī)、輕量這三點(diǎn)。DayNotes 的元數(shù)據(jù)本來(lái)就在 SQLite 里FTS5 虛擬表可以直接建在同一份數(shù)據(jù)庫(kù)文件中不需要額外維護(hù)一個(gè)索引服務(wù)也不引入新的運(yùn)行時(shí)依賴。對(duì)于“本地優(yōu)先”的工具來(lái)說(shuō)這個(gè)方案是復(fù)雜度最低、可控性最高的。還有一個(gè)容易被忽略的好處FTS5 索引跟隨數(shù)據(jù)庫(kù)文件走備份、遷移、同步都統(tǒng)一了。如果將來(lái)要支持多設(shè)備同步索引也可以跟著數(shù)據(jù)庫(kù)一起處理不需要擔(dān)心本地文件和服務(wù)狀態(tài)不一致。這一點(diǎn)在我這種跨平臺(tái)小工具里非常重要。2. SQLite FTS5 做中文全文搜索三個(gè)必須繞開(kāi)的坑FTS5 本身很成熟但它是為英文環(huán)境設(shè)計(jì)的默認(rèn)行為對(duì)中文特別不友好。這幾個(gè)坑我基本是逐個(gè)踩過(guò)來(lái)的每一個(gè)都會(huì)導(dǎo)致“搜索結(jié)果完全不可用”。2.1 unicode61分詞器對(duì)中文等于沒(méi)有分詞FTS5 默認(rèn)的分詞器是 unicode61它按照 Unicode 字符類型做切分。英文、數(shù)字這類能很好處理空格和標(biāo)點(diǎn)作為分隔符每個(gè)單詞建立索引。但中文沒(méi)有空格整段文字在 unicode61 眼里就是一個(gè)連續(xù)的“詞語(yǔ)”所以它只能把整句當(dāng)成一個(gè) token。這會(huì)導(dǎo)致什么后果如果你的筆記里有“知識(shí)筆記軟件”這個(gè)詞你搜索“筆記”FTS5 是匹配不到的因?yàn)樗⑺饕淖钚挝皇钦湓挾皇恰爸R(shí)”“筆記”“軟件”這些詞。我當(dāng)時(shí)第一次跑通搜索輸入“筆記”結(jié)果返回空一度以為自己建表語(yǔ)句寫錯(cuò)了。更麻煩的是FTS5 還默認(rèn)把超長(zhǎng) token 給截?cái)嗄J(rèn)情況下每個(gè)分詞單元的索引上限是 10 個(gè)字符。中文一句話遠(yuǎn)超過(guò)這個(gè)長(zhǎng)度后面的內(nèi)容根本不會(huì)進(jìn)索引也就是說(shuō)搜索“一篇長(zhǎng)文中后半段的某個(gè)詞”永遠(yuǎn)搜不到。要解決這個(gè)問(wèn)題就得繞開(kāi)默認(rèn)分詞器在寫入索引之前自己做分詞把分詞結(jié)果按約定格式填進(jìn)去。這也是我換到 jieba 的根本原因。2.2 用 jieba 預(yù)分詞索引側(cè)和查詢側(cè)要配合確定用 jieba 之后一個(gè)比較自然的思路是寫入時(shí)先把標(biāo)題和正文分詞用空格把詞拼起來(lái)存到 FTS5 表里查詢時(shí)也對(duì)用戶輸入分詞再拼成查詢語(yǔ)句。建表語(yǔ)句我改成了這樣CREATE VIRTUAL TABLE IF NOT EXISTS doc_search USING fts5( doc_id UNINDEXED, title, content_seg, content_raw, tokenize unicode61 );這里content_seg存的是分詞后的文本content_raw存原始正文用來(lái)在結(jié)果列表里做上下文摘要。查詢時(shí)配合 jieba 做同樣的分詞處理import jieba def build_query(text): words [w.strip() for w in jieba.cut(text) if w.strip()] return OR .join(f{w} for w in words)這里有一個(gè)很關(guān)鍵也很容易寫錯(cuò)的細(xì)節(jié)查詢時(shí)拼出來(lái)的每個(gè)詞都要加雙引號(hào)否則 FTS5 會(huì)把用戶輸入當(dāng)成一個(gè)完整的短語(yǔ)去匹配分好詞也沒(méi)用。我當(dāng)時(shí)在這個(gè)地方吃了虧——索引側(cè)分詞做好了查詢側(cè)忘了給詞加引號(hào)結(jié)果搜“筆記軟件”時(shí)命中的是完整的“筆記軟件”短語(yǔ)而不是“筆記”和“軟件”兩個(gè)詞的任意匹配。另外jieba 的默認(rèn)詞庫(kù)對(duì)通用中文處理得不錯(cuò)但對(duì)專業(yè)領(lǐng)域術(shù)語(yǔ)識(shí)別很差。我的筆記里有大量技術(shù)名詞比如“Rust”“Tauri”“unmount”這類中英混合詞默認(rèn)詞典經(jīng)常切得稀碎。解決辦法是維護(hù)一個(gè)自定義詞典文件把高頻術(shù)語(yǔ)加進(jìn)去。2.3 索引同步機(jī)制增刪改怎么保持一致性建立一個(gè)索引只是第一步真正讓人頭疼的是后續(xù)的持續(xù)同步。文檔會(huì)新增、修改、刪除索引如果不跟著變搜索就變成垃圾數(shù)據(jù)展示。我在設(shè)計(jì)上采用了一個(gè)非常樸素的方案在應(yīng)用層做同步不搞數(shù)據(jù)庫(kù)觸發(fā)器。文檔保存的時(shí)候順帶調(diào)用一個(gè)sync_doc_to_index函數(shù)把該文檔從索引里刪掉再重新插入。流程拆開(kāi)看大概是這么幾步文檔保存時(shí)讀取最新的標(biāo)題和正文用 jieba 對(duì)標(biāo)題和正文做分詞先從doc_search里刪除該doc_id的所有舊記錄再插入一條新記錄。這里要注意FTS5 虛擬表沒(méi)有主鍵約束如果用INSERT OR REPLACE去按doc_id覆蓋會(huì)因?yàn)閐oc_id不是真正的主鍵而插入重復(fù)行。所以邏輯上必須是“先刪后插”不能偷懶。剛一開(kāi)始我圖省事只在文檔保存時(shí)同步?jīng)]有處理批量導(dǎo)入的場(chǎng)景。結(jié)果第 10 天我導(dǎo)入一千多篇文檔導(dǎo)入完成后索引是空的因?yàn)榕繉懭肼窂綁焊鶝](méi)有調(diào)用同步函數(shù)。后來(lái)我在導(dǎo)入流程的末尾統(tǒng)一執(zhí)行了一次全量重建索引# 先刪除整個(gè)虛擬表 DROP TABLE IF EXISTS doc_search; # 再建表 # 然后從 docs 表里重新讀取全部分詞寫入全量重建索引其實(shí)沒(méi)有想象中那么慢一千多篇 Markdown 文檔全部重新分詞再寫入在我的筆記本上大概也就是兩秒多。所以日常增量靠保存時(shí)同步批量操作后做一次重建索引一致性的問(wèn)題就基本解決了。3. 本輪踩坑實(shí)錄從“搜不出”到“排序不對(duì)”的完整排查鏈路這一節(jié)我要完整記錄今天遇到的三個(gè)問(wèn)題的排查過(guò)程。之所以寫這么細(xì)是因?yàn)檫@些問(wèn)題的表象和根因離得很遠(yuǎn)光看報(bào)錯(cuò)信息完全無(wú)從下手必須自己一步步推。3.1 搜索“筆記”搜不出“知識(shí)筆記”分詞器的鍋問(wèn)題出現(xiàn)得非常突然。第一輪功能做完之后我輸入“筆記”測(cè)試結(jié)果返回零條。數(shù)據(jù)庫(kù)里明明有十幾篇標(biāo)題帶“筆記”的文檔為什么搜不到排查第一步是驗(yàn)證原始數(shù)據(jù)有沒(méi)有進(jìn)索引。我直接打開(kāi) SQLite查doc_search表里有多少條記錄確認(rèn)數(shù)據(jù)確實(shí)寫入了。第二步是看匹配行為單獨(dú)執(zhí)行SELECT doc_id, title FROM doc_search WHERE doc_search MATCH 筆記;返回空。換一個(gè)查法SELECT doc_id, title FROM doc_search WHERE doc_search MATCH 知識(shí)筆記;居然能查到。這一步基本確認(rèn)了問(wèn)題出在分詞索引里根本沒(méi)有“筆記”這個(gè) token只有“知識(shí)筆記”這種整句 token。原因就是前面說(shuō)的 unicode61 分詞器不切分中文。排查到這里方向已經(jīng)很清楚了不是數(shù)據(jù)問(wèn)題不是查詢語(yǔ)法問(wèn)題是分詞策略問(wèn)題。解決方式不做展開(kāi)——換成 jieba 預(yù)分詞之后重建索引再搜“筆記”能正常命中了。一個(gè)容易忽略的點(diǎn)是重建索引之后舊 token 還殘留在虛擬表里所以排查時(shí)一定記住先 DROP 再重建。3.2 輸入一個(gè)關(guān)鍵字CPU就飆升IPC通信和全表掃描分詞問(wèn)題解決后搜索的核心功能能用了但隨之而來(lái)的是性能問(wèn)題。我在輸入框里打了三個(gè)字應(yīng)用窗口就出現(xiàn)明顯的卡頓系統(tǒng)監(jiān)視器一看CPU 占用直接頂滿。一開(kāi)始我以為是 FTS5 索引查詢本身慢后來(lái)仔細(xì)一想FTS5 對(duì)一千多篇文檔的索引查詢應(yīng)該是毫秒級(jí)不可能是瓶頸。于是我把排查重點(diǎn)放在調(diào)用鏈路上。DayNotes 用的框架里渲染進(jìn)程和主進(jìn)程之間通過(guò) IPC 通信。我的搜索邏輯在主進(jìn)程里執(zhí)行每次輸入框有內(nèi)容變化渲染進(jìn)程就發(fā)一次 IPC 請(qǐng)求。關(guān)鍵在于我監(jiān)聽(tīng)的是input事件每敲一個(gè)字符都會(huì)觸發(fā)一次請(qǐng)求。如果一句搜索詞有五個(gè)字輸入過(guò)程中就發(fā)了五次請(qǐng)求而且主進(jìn)程每次都要連接數(shù)據(jù)庫(kù)、執(zhí)行查詢、把結(jié)果序列化回傳。還有一個(gè)隱藏的性能殺手我在主進(jìn)程的搜索函數(shù)里拿到搜索結(jié)果后會(huì)讀取命中文檔的完整內(nèi)容來(lái)做上下文摘要。一千多篇文檔匹配到幾十篇每篇都要讀文件、截取摘要這個(gè)操作比索引查詢本身慢得多。解決分兩層渲染進(jìn)程側(cè)加防抖用戶停止輸入 300ms 后才發(fā)請(qǐng)求主進(jìn)程側(cè)只查結(jié)果的前 50 條并且摘要直接從 FTS5 表里存好的content_raw字段截取不額外讀磁盤文件。防抖代碼很簡(jiǎn)單大概是這樣的let timer; inputElement.addEventListener(input, () { clearTimeout(timer); timer setTimeout(() { search(inputElement.value); }, 300); });加完之后即使連續(xù)輸入整句話實(shí)際查詢也只觸發(fā)一次CPU 占用基本可以忽略。3.3 標(biāo)題命中的結(jié)果排到了正文后面rank排序修正功能能跑、性能也上去了第三個(gè)問(wèn)題浮出水面搜索結(jié)果排序不對(duì)。按常識(shí)標(biāo)題里包含關(guān)鍵詞的文章優(yōu)先級(jí)應(yīng)該高于正文里碰巧出現(xiàn)一次關(guān)鍵詞的文章。但實(shí)際結(jié)果恰恰相反正文提到的排在前面標(biāo)題命中的卻排到了后面。FTS5 默認(rèn)的排序依據(jù)是 BM25 算法它會(huì)綜合考慮詞頻、文檔長(zhǎng)度等因素打分。這個(gè)打分本身沒(méi)問(wèn)題但它完全不理解“標(biāo)題命中”這件事在業(yè)務(wù)上的重要性。對(duì)于知識(shí)管理工具來(lái)說(shuō)標(biāo)題命中往往意味著這篇文章就是講這個(gè)主題的正文命中可能只是順帶提到。修正方式是給排序加權(quán)重。FTS5 對(duì)每一行會(huì)算出一個(gè)rank值rank越小越靠前。我在ORDER BY里人為加上一個(gè)判斷如果標(biāo)題里包含搜索詞就給這行減一個(gè)固定值讓它排上去SELECT doc_id, title, rank FROM doc_search WHERE doc_search MATCH ? ORDER BY rank CASE WHEN title LIKE % || ? || % THEN -20 ELSE 0 END LIMIT 50;這種加權(quán)方式雖然粗暴但對(duì)于個(gè)人工具完全夠用。再進(jìn)一步還可以給標(biāo)簽命中更高的權(quán)重這個(gè)今天沒(méi)做列進(jìn)了后面的計(jì)劃里。排查過(guò)程中有一個(gè)值得記錄的細(xì)節(jié)很多人會(huì)直接把搜索詞拼進(jìn) SQL 里這在本地單機(jī)工具里問(wèn)題不大但一旦數(shù)據(jù)源來(lái)自第三方就有 SQL 注入風(fēng)險(xiǎn)。FTS5 的正規(guī)寫法是用MATCH ?傳參我全程都用占位符這個(gè)習(xí)慣值得長(zhǎng)期保持。4. 搜索框背后容易被忽略的交互與性能細(xì)節(jié)搜索模塊的核心打通之后剩下的工作主要圍繞“好用”展開(kāi)。功能能跑只是起點(diǎn)真正決定用戶感受的往往是那些技術(shù)棧之外的小細(xì)節(jié)。4.1 300ms防抖加過(guò)期請(qǐng)求丟棄防抖解決了“打字過(guò)程中反復(fù)請(qǐng)求”的問(wèn)題但還有一個(gè)并發(fā)場(chǎng)景沒(méi)處理如果用戶在防抖生效之前快速按了回車上一個(gè)請(qǐng)求還沒(méi)返回新的請(qǐng)求就發(fā)出去了。這種情況下兩個(gè)請(qǐng)求的返回順序是不確定的先發(fā)出的請(qǐng)求后返回就會(huì)把較新的結(jié)果覆蓋掉造成搜索結(jié)果落后于輸入框內(nèi)容。解決辦法是在渲染進(jìn)程維護(hù)一個(gè)自增的請(qǐng)求編號(hào)let requestId 0; async function search(keyword) { const currentId requestId; const results await window.api.search(keyword); if (currentId ! requestId) return; // 過(guò)期結(jié)果直接丟棄 renderResults(results); }這個(gè)模式在很多場(chǎng)景下都通用尤其是桌面端和前端交互。思路很簡(jiǎn)單每次都把請(qǐng)求編號(hào)遞增哪個(gè)結(jié)果回來(lái)時(shí)發(fā)現(xiàn)自己已經(jīng)不是最新編號(hào)了就放棄渲染。4.2 搜索高亮的正確姿勢(shì)先轉(zhuǎn)義再渲染搜索結(jié)果列表里匹配的關(guān)鍵詞需要高亮否則用戶看不出為什么這篇被搜出來(lái)了。我一開(kāi)始直接用正則替換原始正文把命中詞替換成mark命中詞/mark然后塞進(jìn)渲染層。寫完一測(cè)發(fā)現(xiàn)一個(gè)嚴(yán)重安全漏洞——如果正文本身包含 HTML 標(biāo)簽比如一篇講前端開(kāi)發(fā)的筆記里寫了div這個(gè)標(biāo)簽會(huì)被渲染層當(dāng)成真正的 DOM 執(zhí)行。正確順序必須是先把原始文本做 HTML 轉(zhuǎn)義再做高亮替換。比如function escapeHtml(text) { return text .replace(//g, amp;) .replace(//g, lt;) .replace(//g, gt;) .replace(//g, quot;) .replace(//g, #039;); } function highlight(text, terms) { const safe escapeHtml(text); const escapedTerms terms.map(escapeHtml); let result safe; for (const term of escapedTerms) { result result.replaceAll(term, (match) mark${match}/mark); } return result; }先轉(zhuǎn)義再替換既能保證高亮生效又不會(huì)讓原始 HTML 破壞頁(yè)面結(jié)構(gòu)。順便一提replaceAll里面用函數(shù)作為參數(shù)是為了避免$這種特殊替換變量的坑寫的時(shí)候容易被忽略。4.3 空態(tài)、快捷鍵和索引狀態(tài)感知細(xì)節(jié)上我還做了幾個(gè)不起眼但價(jià)值很大的功能。搜索無(wú)結(jié)果時(shí)的空態(tài)我一開(kāi)始只顯示了“沒(méi)有找到匹配內(nèi)容”一行字后來(lái)發(fā)現(xiàn)這樣很容易讓用戶陷入死胡同。現(xiàn)在空態(tài)里會(huì)提示嘗試縮短關(guān)鍵詞、檢查是否有錯(cuò)別字、或者去設(shè)置里重建索引。實(shí)際使用中很多“搜不到”的問(wèn)題根源是索引沒(méi)有跟上給出重建索引的引導(dǎo)能省掉很多用戶困惑。全局快捷鍵CtrlK聚焦搜索框這已經(jīng)是這類工具的標(biāo)配了我之前的編輯器里其實(shí)已經(jīng)有了今天只是把觸發(fā)邏輯統(tǒng)一到搜索組件上。還有一個(gè)小細(xì)節(jié)搜索框里輸入全角空格或者只有空格的字符串時(shí)不會(huì)發(fā)起搜索請(qǐng)求避免又一次無(wú)意義的 IPC。索引狀態(tài)感知也是一個(gè)容易漏掉的功能。我在設(shè)置頁(yè)里增加了一個(gè)“索引信息”面板顯示當(dāng)前索引了多少文檔、最近一次重建時(shí)間、自建詞典的詞條數(shù)。這看起來(lái)像是開(kāi)發(fā)者接口但對(duì)個(gè)人工具來(lái)說(shuō)它是排查“為什么搜不到”的第一入口。5. 30天挑戰(zhàn)過(guò)半我重新思考“搜索”這件事今天是第 11 天項(xiàng)目已過(guò)三分之一正好借這個(gè)機(jī)會(huì)做一次階段性復(fù)盤。我發(fā)現(xiàn)做知識(shí)管理工具搜索不僅僅是一個(gè)功能模塊它在很大程度上決定了用戶對(duì)這個(gè)工具的信任感。5.1 這11天最大的教訓(xùn)接口預(yù)留與過(guò)早優(yōu)化回頭看我前 10 天的代碼最慶幸的是當(dāng)初做存儲(chǔ)層的時(shí)候把“元數(shù)據(jù)”和“正文內(nèi)容”明確分開(kāi)了。文檔表只存標(biāo)題、路徑、標(biāo)簽、創(chuàng)建時(shí)間這些結(jié)構(gòu)化數(shù)據(jù)正文通過(guò)文件路徑按需讀取。這個(gè)設(shè)計(jì)當(dāng)時(shí)只是出于“Markdown 文件本來(lái)就應(yīng)該直接存在磁盤上”的直覺(jué)沒(méi)想到今天加搜索引擎時(shí)幾乎不用改動(dòng)原來(lái)的數(shù)據(jù)層直接在旁邊多建一張 FTS5 虛擬表就接上了。這一點(diǎn)其實(shí)比“一開(kāi)始就設(shè)計(jì)好搜索功能”更重要——前期搜索需求不明確如果強(qiáng)行一開(kāi)始就設(shè)計(jì)索引結(jié)構(gòu)大概率會(huì)根據(jù)錯(cuò)誤的假設(shè)做出過(guò)度設(shè)計(jì)。更合理的做法是保證層與層之間的邊界清晰給未來(lái)的功能留出插入位置而不是提前把所有擴(kuò)展點(diǎn)都實(shí)現(xiàn)。與之相對(duì)的另一個(gè)極端是過(guò)早優(yōu)化。我最初沒(méi)加搜索原因就是覺(jué)得“內(nèi)容少用正則也行”。事實(shí)證明這個(gè)決定是對(duì)的正是因?yàn)閮?nèi)容量到了臨界點(diǎn)、體驗(yàn)真實(shí)惡化我才理解了為什么需要索引而不是憑空想象出一個(gè)性能問(wèn)題。過(guò)早引入 ES 或者重型的搜索服務(wù)只會(huì)讓項(xiàng)目陷入維護(hù)泥潭。5.2 明天的計(jì)劃可配置的詞庫(kù)和重建索引入口雖然今天的搜索功能已經(jīng)能正常使用了但距離“順手”還有一段距離。我整理了幾個(gè)必須要做的東西設(shè)置頁(yè)增加“重建索引”按鈕配合進(jìn)度提示解決用戶遇到搜索異常時(shí)的自救途徑自建詞典的可視化管理方便把常用術(shù)語(yǔ)直接加進(jìn)詞庫(kù)不用改配置文件重啟標(biāo)簽權(quán)重加分讓標(biāo)簽命中排在標(biāo)題命中前面增強(qiáng)檢索業(yè)務(wù)語(yǔ)義搜索歷史記錄把最近的搜索詞存在本地方便重復(fù)查找。這些功能都不復(fù)雜難點(diǎn)在于接口怎么設(shè)計(jì)得順滑。比如重建索引進(jìn)度提示如果索引量少根本不需要進(jìn)度條但如果文檔量上千就必須給用戶一個(gè)明確的“在做什么”的狀態(tài)反饋避免誤以為卡死。寫到這里我想多說(shuō)一句個(gè)人體會(huì)。做本地優(yōu)先的工具最大的幸福感其實(shí)來(lái)自“它能自己持續(xù)變得好用”這件事。前 10 天寫編輯器、寫標(biāo)簽系統(tǒng)是給自己造器皿這一天的搜索功能做出來(lái)之后我每天記錄筆記時(shí)終于敢往里面堆量了因?yàn)槲抑馈刚业玫健惯@個(gè)底線已經(jīng)被守住了。30 天的項(xiàng)目還在繼續(xù)明天繼續(xù)解決新問(wèn)題。