全文搜索這功能聽著簡單真正踩進去才知道水有多深。尤其是在 Vue 3 項目里數(shù)據(jù)量一旦過萬一個簡單的filter就能讓你在輸入框里每敲一個字就卡一下。過去半年我在做內(nèi)部知識庫和商品中臺搜索先后對比了四種主流做法原生filter線性掃描、Fuse.js 模糊搜索、MiniSearch 全文檢索引擎、后端搜索服務以 Meilisearch 為例。從性能、體驗、維護成本三個角度折騰了一輪今天把四套方案的實現(xiàn)思路、測量要點、踩坑記錄都整理出來給正準備在 Vue 3 里做全文搜索的朋友一個可以參考的選型清單。這套對比的思路不限于某一個業(yè)務知識庫、商品搜索、日志檢索、文檔站都可以套用。1. 四種搜索方案我在什么樣的情況下才會選它搜索方案選型不能光看“能不能搜到”還要看數(shù)據(jù)量、部署成本、團隊維護能力。我把整個決策拆成四個層次純前端原生掃描、前端模糊匹配庫、前端全文索引庫、后端搜索引擎。每往上一層搜索能力更強、規(guī)模上限更高但引入的依賴、部署的復雜度也同步上升。1.1 方案一原生 filter 線性掃描原理是把數(shù)組整個過一遍用includes、indexOf或者正則去匹配字符串。這是最簡單也最容易想到的方案零依賴、零構(gòu)建、零學習成本。它適合什么場景我見過很多后臺管理系統(tǒng)的搜索框比如用戶列表按姓名過濾、訂單列表按訂單號過濾這種字段值短、數(shù)據(jù)量幾百到幾千條的場景直接filter完全夠用。還有一個隱含優(yōu)勢它是響應式的computed里寫一句就能聯(lián)動視圖前端新手也能馬上上手。但它的瓶頸非常明顯。一是時間復雜度和數(shù)據(jù)量線性相關(guān)數(shù)據(jù)量從五千漲到五萬、十萬搜索耗時跟著線性漲。二是匹配策略太粗糙includes只能做子串匹配想做大小寫不敏感、忽略標點、按空格劃分多個關(guān)鍵詞全部要自己處理。三是沒有“相關(guān)性”概念結(jié)果順序要么是原始順序要么得手動按某個字段排序。超過一定數(shù)據(jù)量之后它就不是“夠用”而是“硬撐”。1.2 方案二Fuse.js 模糊搜索Fuse.js 解決的核心痛點是“用戶記不住準確關(guān)鍵詞”。它基于編輯距離算法做模糊匹配即使關(guān)鍵詞寫錯一兩個字也能把候選結(jié)果撈出來。實際體驗上這個“容錯”能力特別適合搜索和程序員相關(guān)的技術(shù)名詞比如用戶想搜“Vue 3”卻打成“Vus 3”Fuse.js 能根據(jù)字母相似度匹配到對應結(jié)果。它自帶了權(quán)重系統(tǒng)可以指定標題字段權(quán)重更高、正文字段權(quán)重更低也能返回匹配位置、匹配片段前端拿來做高亮很方便。代價是包體積相對較大gzip 后約 20KB 左右而且模糊匹配本身的計算開銷不小數(shù)據(jù)量越大單次查詢越慢。Fuse.js 提供了createIndex預建索引的能力但只能加速候選篩選匹配計算仍然躲不掉。實測下來一萬條數(shù)據(jù)時帶索引查詢在 40-70ms 左右能接受但到五萬條會明顯吃力。1.3 方案三MiniSearch 全文檢索引擎MiniSearch 走的是和 Fuse.js 完全不同的路子。它在內(nèi)存里構(gòu)建倒排索引把文本拆成 token每個 token 映射到一批文檔。查詢時直接根據(jù) token 取文檔集合而不是逐條掃描。加上內(nèi)置了 BM25 相關(guān)度評分結(jié)果天然按“最相關(guān)”排序體驗非常接近后端搜索引擎。它對中文場景的適配也比想象中好支持自定義tokenize函數(shù)能用分詞器把中文切成詞或詞組再建索引。和 Fuse.js 對比MiniSearch 強在數(shù)據(jù)量越大優(yōu)勢越明顯五萬條、十萬條數(shù)據(jù)查詢也在毫秒級而且包體積小gzip 后通常在幾 KB 到十幾 KB 之間。缺點是它需要管理索引生命周期數(shù)據(jù)新增、修改、刪除時都得調(diào)用對應 API 維護索引比單純filter復雜一些。1.4 方案四后端搜索服務HTTP API當數(shù)據(jù)量到百萬級或者需要多租戶權(quán)限過濾、同義詞擴展、實時同步數(shù)據(jù)庫等能力時純前端方案就扛不住了。此時把搜索拆成獨立的服務前端只負責發(fā)請求和渲染結(jié)果。最常見的后端方案是 Elasticsearch、Meilisearch、Typesense體驗和性能都很強。代價也很明確需要額外部署和維護服務前端要處理接口延遲、loading、錯誤態(tài)、請求競態(tài)。如果是個人項目或小型團隊后端運維成本可能比前端開發(fā)成本還高。所以我的原則是“能用前端解決就別上后端”除非數(shù)據(jù)規(guī)模真的到了前端撐不住的程度。四種方案的定位差異可以看這個表方案搜索能力建議數(shù)據(jù)規(guī)模前端包體積增量維護成本原生 filter子串匹配 5000 條0最低Fuse.js模糊匹配 1 萬條約 20KB低MiniSearch全文索引 BM25 50 萬條約 10KB中后端搜索服務分布式全文檢索百萬級以上極小高2. 性能基準測試一萬到十萬條數(shù)據(jù)誰扛得住講完原理上一波實測數(shù)據(jù)。先說環(huán)境生產(chǎn)構(gòu)建版本 Vite Vue 3.4Chrome 120MacBook Pro M1。數(shù)據(jù)是隨機生成的 5 萬條商品數(shù)據(jù)包含標題10-30 字、分類名、描述100-300 字。這個量級很接近真實的知識庫、商品庫場景。測量方式上所有耗時都用performance.now()在搜索函數(shù)外層計算并且強制瀏覽器完成渲染后才取下一輪數(shù)據(jù)避免把異步渲染時間誤算進搜索結(jié)果里。2.1 構(gòu)建索引耗時與包體積這一輪只測“進入頁面到可以搜索”的初始化成本。原生filter沒有建索引的概念隨便搜Fuse.js 一次性把全量文本讀進內(nèi)存做預處理MiniSearch 需要調(diào)用addAll批量建倒排索引后端方案把建索引的耗時轉(zhuǎn)移到了服務端前端只關(guān)心接口是否可用。我實測的數(shù)據(jù)如下方案構(gòu)建索引耗時前端包體積增量gzip原生 filter0ms0KBFuse.js含 createIndex約 320ms約 21KBMiniSearch約 410ms約 8KBMeilisearch API服務端處理約 1KB結(jié)論很清楚除了原生掃描其余方案首次進入都有毫秒級到幾百毫秒不等的索引構(gòu)建時間。好消息是這些構(gòu)建都只發(fā)生在數(shù)據(jù)加載或數(shù)據(jù)更新時不會持續(xù)卡用戶。如果頁面數(shù)據(jù)本身很大建議用requestIdleCallback或setTimeout分片構(gòu)建索引避免阻塞首屏渲染。2.2 查詢延遲實測P50/P95查詢延遲是最核心的指標。我模擬了連續(xù)輸入關(guān)鍵詞的場景對每個方案在 1 萬條、5 萬條數(shù)據(jù)下分別測了 100 次查詢?nèi)?P50 和 P95。這里只統(tǒng)計純查詢時間不包含防抖等待和渲染時間。方案1 萬條 P501 萬條 P955 萬條 P505 萬條 P95原生 filter8ms15ms38ms62msFuse.js未建索引30ms50ms150ms220msFuse.jscreateIndex18ms35ms70ms120msMiniSearch1ms3ms2ms6msMeilisearch API35ms70ms48ms85ms這個表格能看出很多問題。原生filter在 1 萬條時還挺快到了 5 萬條 P95 就有 60ms 以上配合每敲一個字就觸發(fā)查詢的交互設計用戶體感就是“卡”。Fuse.js 雖然有模糊匹配能力但在 5 萬條時掉到 120-220ms已經(jīng)明顯影響輸入體驗。MiniSearch 是唯一一個在 5 萬條下依然維持在毫秒級的純前端方案。Meilisearch 的延遲主要在網(wǎng)絡 RTT所以數(shù)據(jù)量變化影響反而不大。2.3 內(nèi)存占用與長期運行穩(wěn)定性內(nèi)存這塊我單獨提一下因為很多開發(fā)者只看搜索耗時而忽略內(nèi)存泄漏。我打開 Chrome DevTools 的 Memory 面板記錄每種方案在完成 5 萬條索引構(gòu)建后的“保留內(nèi)存”變化。原生filter和 Fuse.js不建索引幾乎沒有額外內(nèi)存占用。Fuse.js 使用createIndex后5 萬條數(shù)據(jù)大約多占用 30-50MB 內(nèi)存。MiniSearch 的倒排索引會保留詞項到文檔的映射同樣數(shù)據(jù)集下大概占用 40-60MB。后端方案前端內(nèi)存占用最小但服務端要吃資源。更重要的是如果用戶在搜索期間頻繁輸入、反復觸發(fā)索引重建內(nèi)存可能只增不減。Vue 的響應式系統(tǒng)會額外放大這個問題——把大數(shù)組放進reactive后每次改動都觸發(fā)依賴收集和重渲染。我后來的做法是大列表用shallowRef甚至普通變量維護只有最終展示給用戶的結(jié)果集才放進ref這一步能省掉大量無意義的響應式代理開銷。3. 四種方案在 Vue 3 里的完整接入實現(xiàn)方案選型只是第一步落地才是考驗。這一節(jié)把四個方案的 Vue 3 接入代碼寫出來包含我自己常用的封裝方式兼容 Options API 和 Composition API 的讀者都能看懂。3.1 原生 filter 接入computed 驅(qū)動的搜索原生方案的核心是用computed緩存搜索結(jié)果避免每次渲染都重新過濾。搜索關(guān)鍵詞用一個ref維護配合watch或輸入框的v-model同步。// useLocalSearch.js import { ref, computed } from vue export function useLocalSearch(list, searchFields [title, content]) { const keyword ref() const results computed(() { const kw keyword.value.trim().toLowerCase() if (!kw) return list.value return list.value.filter((item) { return searchFields.some((field) { const value item[field] return value ! null String(value).toLowerCase().includes(kw) }) }) }) return { keyword, results } }這里有個關(guān)鍵細節(jié)computed的緩存依賴是keyword.value和list.value順序很重要。如果在組件里對list做了額外過濾比如“只顯示上架商品”一定要先處理完業(yè)務過濾再傳入useLocalSearch否則搜索結(jié)果可能出現(xiàn)“被過濾掉的商品仍然命中”的 bug。我通常在組件里這樣用script setup import { useLocalSearch } from ./useLocalSearch import { goodsList } from ./api/goods const { keyword, results } useLocalSearch(goodsList, [title, category]) /script template input v-modelkeyword placeholder搜索商品名稱或分類 / ul li v-foritem in results :keyitem.id{{ item.title }}/li /ul /template這個方案唯一要防的是重復渲染。computed已經(jīng)能擋住大多數(shù)無效計算但如果搜索結(jié)果依然是一個很大的數(shù)組建議在模板里配合v-memo或在渲染列表時加上分頁/虛擬滾動避免一次性渲染幾千個節(jié)點。3.2 Fuse.js 接入權(quán)重、閾值和防抖聯(lián)動Fuse.js 的核心配置是threshold和keys。threshold控制模糊匹配的寬容度取值范圍 0 到 10 表示完全精確1 表示任意匹配。我常用的值是 0.4容錯和準確率的平衡點。// useFuseSearch.js import Fuse from fuse.js import { ref, watch, shallowRef } from vue import { debounce } from lodash-es export function useFuseSearch(list, options {}) { const keyword ref() const results ref([]) const fuse shallowRef(null) const buildIndex () { fuse.value new Fuse(list.value, { keys: [title, content], threshold: 0.4, ignoreLocation: true, minMatchCharLength: 2, includeMatches: true, includeScore: true, useExtendedSearch: true, ...options, }) } watch(list, buildIndex, { immediate: true }) const runSearch debounce((kw) { if (!kw.trim()) { results.value list.value return } results.value fuse.value.search(kw).map((r) r.item) }, 200) watch(keyword, (kw) runSearch(kw)) return { keyword, results } }幾個容易踩的坑ignoreLocation: true很重要。默認 Fuse.js 會考慮關(guān)鍵詞在文本中的位置開啟后不再因為關(guān)鍵詞出現(xiàn)在靠后位置而懲罰分數(shù)對于全文搜索更合理。minMatchCharLength: 2避免了用戶輸入一個字符時匹配出一大堆無關(guān)結(jié)果。includeMatches打開后可以在結(jié)果對象里拿到匹配位置數(shù)組做高亮方便。但注意我上面的寫法把r.item返回出去了如果需要匹配片段得改成返回整個r。Fuse.js 的createIndex預建索引用法是在初始化時傳入new Fuse(list, { ..., useExtendedSearch: true })后調(diào)用fuse.setCollection或者直接用Fuse.createIndex(keys, list)把序列化索引存入內(nèi)存。這個索引能顯著減少候選文檔數(shù)量但計算量仍然不小數(shù)據(jù)超過一萬條后建議優(yōu)先考慮 MiniSearch。3.3 MiniSearch 接入倒排索引的構(gòu)建、查詢與增量更新MiniSearch 的接入流程分三步初始化、建索引、搜索。它和 Fuse.js 最大的不同是“先建索引再搜”所以數(shù)據(jù)更新時必須同步維護索引。// useMiniSearch.js import MiniSearch from minisearch import { ref, shallowRef, watch } from vue export function useMiniSearch(list, options {}) { const keyword ref() const results ref([]) const searchIndex shallowRef(null) const initIndex () { const mini new MiniSearch({ fields: [title, content], storeFields: [title, content, category, updatedAt], searchOptions: { boost: { title: 2, content: 1 }, prefix: true, fuzzy: 0.2, }, ...options, }) mini.addAll(list.value) searchIndex.value mini } watch(list, initIndex, { immediate: true }) watch(keyword, (kw) { if (!searchIndex.value) return if (!kw.trim()) { results.value list.value return } results.value searchIndex.value.search(kw, { combineWith: AND }) }) return { keyword, results } }這里searchOptions.boost設置了標題字段的權(quán)重是正文字段的兩倍搜索排序會優(yōu)先展示標題命中的內(nèi)容。prefix: true開啟前綴匹配用戶輸入“手機會”也能匹配到“手機配件、手機支架”等以“手機”開頭的結(jié)果。fuzzy: 0.2允許極小的拼寫誤差。增量更新是 MiniSearch 使用者的必修課。新增文檔用add刪除用discard修改就是先discard再add。如果不做增量更新而是一口氣調(diào)用addAll重建全量索引五萬條數(shù)據(jù)的構(gòu)建時間就會在每次數(shù)據(jù)變更時重復出現(xiàn)界面明顯卡頓。一個從實踐中得到的建議MiniSearch 的search返回的是文檔 ID 加權(quán)重分數(shù)如果你只需要結(jié)果列表不要map成完整文檔對象直接讓results.value持有 MiniSearch 返回的格式渲染時再關(guān)聯(lián)查原始數(shù)據(jù)。這樣可以省下大量對象拷貝。3.4 后端搜索 API 接入請求競態(tài)與 loading 處理接入后端搜索前端代碼反而更簡單但多了一個必須處理的并發(fā)問題用戶快速輸入時舊請求的響應可能比新請求晚到導致結(jié)果閃爍或錯誤覆蓋。解決辦法是給請求加“序列號”只接受最新一次請求的響應。// useRemoteSearch.js import { ref, watch } from vue import { debounce } from lodash-es export function useRemoteSearch(searchFn, { delay 300 } {}) { const keyword ref() const results ref([]) const loading ref(false) const error ref(null) let requestSeq 0 watch( keyword, debounce(async (kw) { const currentSeq requestSeq loading.value true error.value null try { const data await searchFn(kw) if (currentSeq ! requestSeq) return results.value data } catch (e) { if (currentSeq ! requestSeq) return error.value e } finally { if (currentSeq requestSeq) { loading.value false } } }, delay) ) return { keyword, results, loading, error } }requestSeq這個變量就是競態(tài)處理的鑰匙。每次請求前自增一次響應回來后對比當前的requestSeq如果不是最新的就直接丟棄。這個方法比AbortController更輕量因為AbortController在取消請求時會在某些瀏覽器里拋異常而序列號方案不會產(chǎn)生額外的錯誤日志。后端接口的返回結(jié)構(gòu)建議統(tǒng)一成{ hits: [], total: number }前端拿到total做分頁或“共 N 條結(jié)果”的提示比在結(jié)果數(shù)組上length更準確。4. 體驗細節(jié)高亮、分詞、渲染與排序性能數(shù)據(jù)只是地基用戶真正感知到的是交互體驗。很多人測試時只關(guān)注“能不能搜出來”忽略了搜索框本身的設計。這一節(jié)聊幾個我在實際項目里打磨過的細節(jié)每一項都對最終體驗有實打?qū)嵉挠绊憽?.1 輸入防抖、最小字符數(shù)與空狀態(tài)設計搜索輸入框最常見的錯誤是“每敲一個字符都觸發(fā)一次搜索”。即使 MiniSearch 查詢只要幾毫秒渲染層和響應式更新也可能讓低端手機掉幀。我的統(tǒng)一做法是加 200-300ms 的防抖同時限制至少輸入 2 個字符才發(fā)起搜索避免用戶輸入單個字母時頁面陷入“什么都沒輸入但結(jié)果已經(jīng)變了”的混亂。空狀態(tài)設計也很重要。關(guān)鍵詞為空時通常展示全部數(shù)據(jù)或熱門推薦搜索無結(jié)果時展示友好的提示和“清空搜索”按鈕。我習慣在組件里同時維護兩個狀態(tài)results搜索結(jié)果和isSearching是否為搜索模式而不是讓組件傻傻地把空數(shù)組渲染成空白頁。防抖在 Vue 里要注意一個坑debounce的函數(shù)如果直接包裝watch回調(diào)會導致watch的immediate失效。如果需要在初始化時執(zhí)行一次搜索別依賴防抖單獨調(diào)用一次搜索函數(shù)即可。4.2 搜索結(jié)果高亮的正確寫法高亮最常見的實現(xiàn)是用v-html直接把帶mark標簽的字符串渲染出來。這個寫法有 XSS 風險而且容易被用戶輸入的特殊字符打斷正則。安全的做法分兩步先轉(zhuǎn)義 HTML再在轉(zhuǎn)義后的文本里做關(guān)鍵詞高亮。function escapeHtml(str) { return String(str) .replace(//g, amp;) .replace(//g, lt;) .replace(//g, gt;) .replace(//g, quot;) .replace(//g, #39;) } function escapeRegExp(str) { return String(str).replace(/[.*?^${}()|[\]\\]/g, \\$) } function highlight(text, keyword) { const safeText escapeHtml(text) const words keyword.trim().split(/\s/).filter(Boolean) if (!words.length) return safeText const pattern words.map((w) escapeRegExp(escapeHtml(w))).join(|) return safeText.replace(new RegExp((${pattern}), gi), mark$1/mark) }這個函數(shù)的關(guān)鍵是escapeRegExp必須先于escapeHtml處理否則用戶輸入(、)、$等特殊字符會讓正則報錯。模板里直接span v-htmlhighlight(item.title, keyword)/span注意高亮的粒度不要過細。有的開發(fā)者會把每個字符都包一個mark結(jié)果整個標題變成一整片黃色視覺上非常難看。更合理的做法是對每個關(guān)鍵詞整體高亮不同關(guān)鍵詞之間可以繼續(xù)累積。4.3 中文分詞的坑和應對中文搜索和英文搜索完全不是一回事。英文按空格自然分詞中文的“我是一個前端工程師”是一整串連續(xù)字符。如果你直接用split( )分詞中文文本根本不會分。這個問題的連鎖反應是搜索“前端”時包含“我是一個前端工程師”的文檔可以匹配但搜索“前端工程”時由于文檔里沒有完全相同的子串純includes或 MiniSearch 默認分詞就匹配不到。最簡單的應對是使用Intl.Segmenter這是瀏覽器原生支持的中文分詞 APIconst segmenter new Intl.Segmenter(zh, { granularity: word }) function tokenize(text) { return [...segmenter.segment(text)] .map((seg) seg.segment) .filter((word) word.trim().length 1) }放到 MiniSearch 里就是自定義tokenizeconst searchIndex new MiniSearch({ fields: [title, content], tokenize, searchOptions: { combineWith: AND }, })這里我踩過兩個大坑一是Intl.Segmenter在現(xiàn)代瀏覽器都支持但在低版本 WebView 里可能是 undefined建議做降級處理比如回退到text.match(/[\u4e00-\u9fa5]|[a-zA-Z0-9]/g)這種簡單的正則切詞。二是分詞器開銷不小如果數(shù)據(jù)量大盡量在索引構(gòu)建階段完成分詞不要每次搜索時都分詞。4.4 大列表渲染優(yōu)化從全量渲染到虛擬列表搜索結(jié)果幾十條還好如果是全文搜索返回幾千條匹配結(jié)果也正常。此時直接v-for渲染全量列表DOM 節(jié)點數(shù)可能破萬低端設備立刻白屏或長時間無響應。我嘗試過兩個優(yōu)化方案。最直接的是“截斷顯示”只顯示前 50 條或前 100 條底部加“加載更多”按鈕。這個方案適合大多數(shù)業(yè)務場景尤其是列表本身有分頁邏輯時。另一個是虛擬列表核心思想是只渲染可視區(qū)域內(nèi)的元素滾到哪渲染到哪。Vue 3 生態(tài)里vue-virtual-scroller、tanstack/vue-virtual都比較好用。我用tanstack/vue-virtual寫過一版商品搜索列表關(guān)鍵代碼是這樣script setup import { useVirtualizer } from tanstack/vue-virtual const parentRef ref(null) const virtualizer useVirtualizer({ count: results.value.length, getScrollElement: () parentRef.value, estimateSize: () 60, overscan: 10, }) /script template div refparentRef classscroll-area styleheight: 600px; overflow: auto div :style{ height: virtualizer.getTotalSize() px } div v-foritem in virtualizer.getVirtualItems() :keyitem.key :style{ position: absolute, top: 0, left: 0, width: 100%, transform: translateY(${item.start}px), } {{ results[item.index].title }} /div /div /div /template虛擬列表適合結(jié)果集很大且需要滾動查看的場景。但要注意虛擬列表的內(nèi)部狀態(tài)和搜索結(jié)果是耦合的。搜索關(guān)鍵詞變化時虛擬列表需要回到頂部否則視覺上會出現(xiàn)用戶停留在列表中間、結(jié)果已經(jīng)刷新但滾動位置沒變的怪異現(xiàn)象。5. 常見問題與排查技巧實錄每個做過搜索功能的人都遇到過類似的問題搜索“卡成狗”、中文搜不到、請求亂序覆蓋、內(nèi)存持續(xù)上漲。這些問題往往不是搜不到結(jié)果而是細節(jié)處理不到位。我把實操中遇到的典型問題記錄在這里每個都給出了排查思路和解決建議。5.1 搜索越來越慢索引過期與內(nèi)存泄漏癥狀是剛進入頁面搜索很快幾分鐘后越來越慢最后幾乎卡死。常見原因有三個第一搜索數(shù)據(jù)被放進了reactive。Vue 的響應式系統(tǒng)會遞歸代理整個對象數(shù)組搜索時每次訪問字段都會觸發(fā)依賴收集。數(shù)據(jù)量一大這個開銷遠超搜索本身。排查方式是看 Chrome DevTools 的 Performance 面板里是不是大量時間花在Track Operations上。解決辦法是把大數(shù)組換成shallowRef或普通變量只用響應式數(shù)據(jù)保存keyword和最終的results。第二搜索內(nèi)部緩存了過多的歷史查詢結(jié)果。比如每次輸入都生成一個新的搜索結(jié)果數(shù)組但舊數(shù)組沒有被釋放。排查方式是打開 Memory 面板拍幾次 heap snapshot看Array或Object的數(shù)量是否持續(xù)增長。解決方法是保證results.value每次都被重新賦值而不是push進已有數(shù)組。第三Fuse.js 或 MiniSearch 在數(shù)據(jù)更新時直接重建整個索引。如果數(shù)據(jù)量很大重建索引的時間會指數(shù)級上漲。MiniSearch 必須走discardadd的增量更新Fuse.js 則盡量少地調(diào)用setCollection。5.2 中文搜不到分詞器才是元兇我遇到過最典型的場景是搜索“vue”能匹配“vue3”也能匹配搜索“前端開發(fā)”就什么都搜不到。原因是默認分詞器把“前端開發(fā)”當作一個完整 token 存進索引用戶輸入“前端開發(fā)”時理論上能匹配到完全相同的 token但如果用戶輸入的是“前端開”或“前端”索引里沒有對應 token自然搜不到。解決辦法就是 4.3 里提到的自定義tokenize用Intl.Segmenter或正則把中文切得更細。分詞粒度也要平衡切太細每個字一個 token會導致搜索結(jié)果過多、噪聲大切太粗整句一個 token又會導致查不全。我實踐下來按詞切分、過濾單字和停用詞是相對穩(wěn)妥的選擇。5.3 接口競態(tài)最后一條響應不一定是最后一次請求后端搜索服務最常見的體驗問題是“搜索了 A 詞又馬上搜索 B 詞頁面先顯示 B 的結(jié)果再閃回 A 的結(jié)果”。這是典型的請求競態(tài)。低速網(wǎng)絡或異步任務多時更容易出現(xiàn)。解決方式在 3.4 已經(jīng)寫過用請求序列號或AbortController都行。我推薦序列號方案因為它不受瀏覽器兼容性影響也不用處理AbortError。要注意的是序列號不能放在組件內(nèi)部應該放到useRemoteSearch的閉包里確保每個搜索實例有獨立狀態(tài)。5.4 選型決策速查表最后整理一張速查表可以直接貼在項目文檔里判斷條件推薦方案數(shù)據(jù)量 5000需求只是按字段過濾原生 filter字段少用戶可能拼錯詞需要容錯Fuse.js數(shù)據(jù)量 5 千到 50 萬全文檢索為主MiniSearch數(shù)據(jù)量百萬以上需要多租戶/權(quán)限過濾后端搜索服務Meilisearch/ES團隊無后端運維人力純前端項目MiniSearch已有后端搜索服務前端只是展示層調(diào)用 API 封裝請求這個表不是死規(guī)矩。如果你的項目數(shù)據(jù)量小但字段嵌套深原生filter寫起來很費勁Fuse.js 會更省心。如果數(shù)據(jù)量很大但允許離線靜態(tài)索引也有純前端的 FlexSearch 這類高性能方案。關(guān)鍵是先搞清楚自己卡在哪個階段——是數(shù)據(jù)量、匹配精度還是用戶體驗。從我自己的項目經(jīng)驗看很多搜索體驗問題都不是“搜不出結(jié)果”而是“結(jié)果太多、太慢、太亂”。先確定數(shù)據(jù)規(guī)模再決定要不要上重型方案比一上來就套一個大而全的搜索框架要踏實得多。最后再分享一個小技巧無論選哪種方案一定要準備一份固定的測試數(shù)據(jù)把真實的 1 萬條、5 萬條數(shù)據(jù)提前放好每次改動搜索策略后跑一遍對比別等到用戶投訴才回頭查性能。