企业官网建设流程全解析

开头

如果你做过前端搜索、做过站内文档查询，大概率和我一样，一开始图省事直接上 Elasticsearch，后来发现本地小项目根本扛不动那套重型服务。再后来大家开始用 FlexSearch、Lunr.js 这些轻量方案，可试过一圈之后你会发现：要么体积不够友好，要么配置复杂，要么对中文支持含糊不清。我最近在一个文档型网站里做全文检索时，试着把搜索引擎换成了这个叫caveman的 npm 库——名字看着像“洞穴人”，实际上是一个极简风格的 JS 全文搜索引擎。它最吸引我的点在于：无依赖、核心逻辑压到几百行、搜索速度极快，而且能直接在浏览器跑。

这篇内容不是讲考古也不是讲原始人，我围绕的是一枚实打实的前端搜索库。如果你正在做静态博客站内搜索、知识库筛选、标签过滤、甚至只是想在表格前端加一个快速查找功能，caveman 这套轻量方案很值得花时间了解。这篇会把它拆得很细，包括底层原理、参数配置、实操示例、性能表现、常见坑和我的真实使用体会。无论你是刚接触前端检索的新手，还是已经在用其他搜索引擎想横向对比的老手，照着这篇基本能上手跑起来。

1. caveman 整体设计与思路拆解

1.1 它到底解决了什么问题

很多人手机里装了各种各样的“本地搜索工具”，但又嫌弃它们占用空间大、启动慢，caveman 解决的核心痛点就是这种“杀鸡用牛刀”的尴尬。它是专门为前端场景设计的轻量级全文搜索引擎，核心定位是：在有限的资源、有限的语料规模内，用最少的代码量完成搜索匹配。

caveman 的英文直译是“穴居人”，作者起这个名字的意图很明显——它就是刻意走“返璞归真”的路线。和 Elasticsearch 这种重型的分布式搜索引擎相比，它不需要独立的服务端节点，不需要维护索引分片，不需要学习复杂的查询 DSL。你只需要一个数组、一个配置对象，就能把搜索能力直接嵌进页面。

那么它解决了什么问题呢？以我实际使用的场景为例：我做了一个工具文档站，大概有 300 多篇文章，每篇标题加摘要加正文，总共不过 2MB 左右的文本数据。如果按照传统思路，要么在后端跑一个搜索服务，要么在前端引入动辄几百 KB 的搜索库。caveman 的做法很简单——它在页面加载时把全部文本打成“token 令牌”，然后按照提前算好的索引结构匹配，整个体积只有几个 KB，加载速度几乎可以忽略不计。

这套思路特别适合以下几类人：一是写静态博客想加站内搜索的；二是做企业官网想给产品列表加快速筛选的；三是开发轻量级小工具、电子表格、知识库应用，不想为了一个搜索功能去部署后端服务的。说到底，caveman 适合的场景就是：数据量在几万条以内、搜索逻辑不复杂、要求开箱即用立即上线。

1.2 为什么选择“毫秒级查索引”而不是“服务端搜索”

这里要展开一个关键选择：为什么我不直接用传统的服务端搜索，而要把索引建到浏览器端？

最直接的理由当然是成本和服务维护。很多中小型项目并没有专门的后端，或者后端只是一套简单的 API。如果为了一个搜索框，你还需要去搭建独立搜索服务、定期同步数据、处理集群的负载问题，那这个搜索功能本身就是一场灾难。caveman 的做法是把索引生成这一步也搬到前端，所有数据都以纯 JS 对象的形式存在，浏览器加载后直接内存里跑。

更深一层的原因还在于响应速度。服务端搜索怎么着都得走一遍网络请求，就算优化得再好，也会有明显的网络延迟。而纯前端搜索省掉了服务器往返时间，输入关键词后立即在当前页面完成匹配，交互体验完全是“零等待”。我实测过，在 2 万条短语的规模下，caveman 的处理时间通常只有几毫秒到十几毫秒，基本感觉不到任何卡顿。

还有一点，就是数据隐私和离线能力。如果你做一个纯静态网站，把搜索数据放进前端意味着不需要把搜索请求转发给任何第三方，对于很多不擅长部署搜索服务的个人开发者来说，这种“本地化”方案更省心。这也契合了 caveman 的“穴居人”气质——工具要能用，更要能简单粗暴地工作，不要动不动就引入一套复杂的生态。

1.3 它的核心算法逻辑：拆分与匹配

caveman 之所以能跑得这么快，核心秘密在于它把搜索过程拆成了两个阶段：预构建查询表和实时匹配。

在预构建阶段，它会把每一条记录转换成一组“token”，这组 token 你可以理解为字符串被切分后的最小单元。然后它建立一个从 token 到原始记录的映射表，全称是“倒排索引”，也就是反过来根据内容找位置，而不是像普通文本搜索那样一页一页翻。比如原始记录里头包含“caveman search”，那么“caveman”和“search”都会被映射到这条记录上，搜索任何一个词都能定位到它。

到了实时匹配阶段，用户输入“cav man”这样的不完整短语，caveman 就会对输入的短语同样做拆分，再去倒排索引里找对应条目。它内部用的是变种的二分查找加上一些字符串比较优化，所以查找过程中不需要全表遍历，而是层层缩小范围。这种“空间换时间”的思路非常巧妙：构建索引时占一点内存，但换来查询时极少的时间消耗。

这就像你去图书馆找一本书，没有索引时只能沿着书架从头到尾摸一遍，而有索引卡后，直接按编号跳到对应的那一排，差别是数量级的。caveman 就是帮你手工维护了一批“索引卡”，前端查询时只要查卡就行，完全不需要翻阅全部“书页”。

2. 核心细节解析与实操要点

2.1 安装与基础引入方式

先不聊太深的理论，直接上手是最快的。caveman 是一个标准的 npm 包，安装非常简单，在项目目录执行下面这行命令：

npm install caveman

如果你用的是 CDN 方式，也可以直接在 HTML 里引入。它暴露的是全局对象 Caveman，然后你直接调用它的 createSearchEngine 方法，就能创造出一个独立的搜索实例。这里要注意，createSearchEngine 是工厂方法，你每调用一次就会生成一个拥有自己索引配置的新实例，互不干扰。

import { createSearchEngine } from 'caveman'; const searchEngine = createSearchEngine({ // 此处放置配置参数 });

如果你是在 React 或 Vue 这类框架里使用，建议把它放在组件模块的顶层或一个单独的 util 文件里，避免每次渲染组件都重新创建引擎。因为每次初始化都会对数据集做一次预构建，重复初始化会浪费不必要的计算时间。

2.2 createSearchEngine 关键参数逐个说

caveman 的配置项并不多，但每个都值得仔细调。我按实际使用顺序一条一条说：

searchOptions：这是核心查询选项对象，控制匹配行为。它支持 limit、threshold、sort 和 keys 等配置。limit 控制返回记录的最大条数，默认是 10 条；threshold 是匹配阈值，表示字符匹配的比例下限，范围在 0 到 1 之间，默认是 0.4，数值越大匹配要求越严格；sort 允许传一个比较函数，用来对匹配结果排序；keys 用于指定从数据对象的哪些字段进行索引。

minChars：这个参数的意思是，用户至少输入几个字符才触发搜索。默认值是 1，也就是说输入单个字母就开始搜，但这样可能会产生过多无效匹配。我实际项目里一般设置为 2，因为在中文场景下，单个字触发搜索会导致大量噪声，输入两个或以上字符时才触发会舒服很多。

tokenizer：这是一个自定义分词函数，默认内置的 tokenizer 只是简单按空格和标点拆分字符串。你可以在里面针对中文、数字、URL 等做专属处理，后面我会专门讲这一点。

debug：布尔值，开启后会在控制台输出每个搜索关键词的执行耗时、匹配数量等信息，对排查问题非常有用。

rawData：如果你希望数据源不是数组对象，而是直接传入字符串，可以关闭 rawData，caveman 会把整个字符串当作单条记录处理。

这些参数看着简单，实际搭配起来直接影响搜索质量。比如 threshold 设置得过高，就会导致用户输入稍微不准确就搜不到结果；设置得过低，又会返回大量跟关键词根本无关的垃圾结果。我开发中习惯先把 threshold 保留在默认值跑一轮，再用 debug 模式观察输出结果，最后根据实际命中情况微调。

2.3 索引构建过程与 updateDocument 动态更新

caveman 提供了一个非常重要的方法 updateDocument，它允许你在运行过程中向引擎新增或更新单条记录。这个功能很有价值，因为很多网站的内容并不是一次全部加载完，而是用户滚动加载、或者从服务端异步获取。如果每次新数据到达都要重新调用 setData 全量重建索引，那性能和体验都会出现问题。

我常用的做法是：页面初始化时先 setData 设置一批基础数据，然后在异步获取到新文章或新商品后，用 updateDocument 逐条或分批更新索引。

searchEngine.setData([ { id: 1, title: 'caveman 入门' }, { id: 2, title: 'caveman 原理' } ]); // 异步拿到新数据 searchEngine.updateDocument({ id: 3, title: 'caveman 进阶实战' });

updateDocument 接受一个对象，对象里必须包含匹配 keys 字段的键名。如果你的数据没有唯一标识，建议在数据源里加一个 id 字段，方便后续进行精确删除或更新。

这里有一个注意点：默认的 token 是按空格拆分的，所以对英文效果很好，但对中文来说，一个句子就会被当成一个长 token，搜索时很难命中。这也是很多英文搜索库在中文场景下水土不服的原因，后面第三节我会专门说我自己用的中文适配方案。

2.4 返回结果结构与 limit 调优策略

搜索完成后，search 方法返回的是一个数组，数组元素是命中的原记录对象。如果需要知道每条记录命中哪些字段、以及匹配分数，可以在 options 里开启 debug，或者检查返回记录是不是带有内部标记字段。

在配置 limit 时，我建议根据当前页面承载能力来定。如果是搜索下拉框，一般 5 到 8 条就够了；如果是独立的搜索结果页，可以放大到 20 到 50 条。limit 并非越大越好，因为它会直接占用列表渲染性能，尤其是每条记录内容很长、还附带摘要信息时，渲染成本会成倍增长。

另外，sort 参数发挥作用的地方就在这里。默认排序是按照内部索引顺序返回，但如果数据有更新时间字段，或者你认为某些记录优先级更高，就可以通过 sort 函数控制返回顺序：

searchEngine.search(query, { limit: 20, sort: (a, b) => (a.updateTime < b.updateTime ? 1 : -1) });

3. 实操过程与核心环节实现

3.1 从零搭一个简单的文档站搜索

我先分享一个完整可复现的示例，这个示例模拟的是文档站搜索功能。数据源是文档列表，每条记录包含标题、标签和正文内容。我们直接用 Vite 初始化一个空项目，然后安装 caveman。

npm create vite@latest doc-search --template vanilla cd doc-search npm install caveman

接着新建一个 docSearch.js 文件，把引擎初始化和数据处理逻辑写进去。

import { createSearchEngine } from 'caveman'; const docs = [ { id: 1, title: 'caveman 安装指南', tags: ['install', 'quickstart'], content: '使用 npm 或 yarn 安装 caveman，并完成基础配置。' }, { id: 2, title: 'caveman 参数详解', tags: ['config', 'api'], content: '介绍 searchOptions, minChars, tokenizer 等核心参数的使用方法。' }, { id: 3, title: 'caveman 中文搜索支持', tags: ['chinese', 'language'], content: '通过自定义分词器实现中文搜索能力，解决默认token按空格拆分的缺陷。' }, { id: 4, title: 'caveman 性能优化实践', tags: ['performance', 'optimization'], content: '通过限制阈值、调整limit、建立缓存来提升大语料场景下的搜索性能。' } ]; const searchEngine = createSearchEngine({ minChars: 2, searchOptions: { limit: 10, threshold: 0.5, keys: ['title', 'tags', 'content'] }, debug: true }); searchEngine.setData(docs); export function searchDocs(query) { return searchEngine.search(query); }

在 main.js 里我们绑定一个输入框事件，每输入一个关键词，就调用 searchDocs 并在容器中渲染结果。整个过程不涉及任何后端请求，完全是本地计算。

import { searchDocs } from './docSearch.js'; const input = document.querySelector('#searchInput'); const list = document.querySelector('#resultList'); input.addEventListener('input', (e) => { const query = e.target.value.trim(); const results = query ? searchDocs(query) : []; list.innerHTML = results .map((doc) => `<li><h3>${doc.title}</h3><p>${doc.content}</p></li>`) .join(''); });

这里面有一个小细节：输入框事件是 input，而不是 change。change 只在失去焦点时才触发，input 每敲一个字符都会触发，这样搜索体验才能做到“即时反馈”。配合 minChars 为 2 的设置，前两个字符不会触发搜索，能有效减少无谓的计算。

跑一轮之后你会发现，搜索“中文”或者“参数”都能正确命中对应文档，速度很快，代码也非常短。整套逻辑下来，Caveman 的核心 API 使用基本上已经覆盖了百分之八十。

3.2 自定义 tokenizer：让中文搜索脱胎换骨

默认的 tokenizer 会把文本按空格和标点切分，这种逻辑在英文下没问题，但在中文里就会变成灾难。因为“中文搜索支持”这六个字如果不分词，会被当成一个完整的 token 去匹配，用户输入“中文”两个字，永远也找不到它。

要解决这个问题，必须自己实现 tokenizer。caveman 的 tokenizer 接口接收一个字符串，需要返回一个 token 数组。

我测试下来比较可靠的做法是：先把文本按常用标点和空格拆开，再对每一段中文做“二元分词”，也就是把相邻的两个字符组成一个 token。比如“中文搜索”会被拆成“中文”“文搜”“搜索”三个 token。这样用户无论输入“中文”还是“搜索”，都能命中这条记录。代价是索引体积会比一元分词大一些，但对于几万条级别的数据来说完全够用。

function chineseTokenizer(text) { const tokens = []; const cleanText = text.replace(/[，。！？、（）\s]+/g, ' ').trim(); const parts = cleanText.split(' '); for (const part of parts) { if (part.length === 0) continue; // 判断是否主要是中文 if (/[\u4e00-\u9fa5]/.test(part)) { for (let i = 0; i < part.length - 1; i++) { tokens.push(part.slice(i, i + 2)); } // 保留整词，便于精确匹配 tokens.push(part); } else { tokens.push(part); } } return tokens; } const searchEngine = createSearchEngine({ minChars: 2, tokenizer: chineseTokenizer, searchOptions: { keys: ['title', 'tags', 'content'] } });

这里我做了两个策略叠加：既保留整词，又加入二元分词。整词是为了让用户输入完整标题时能精确命中，二元分词是为了处理部分匹配的情况。实测下来，这种组合在中文场景里表现稳定，基本能覆盖大部分搜索意图。

3.3 大数据量下的性能实测与基准参考

在真实项目中，大家最担心的还是性能。我专门在本地做了一个基准测试：生成 5 万条不重复的文档记录，每条记录大约 200 字，总共大概 10MB 的文本量，然后测试初始化时间和查询耗时。

初始化时间：第一次 setData 构建索引，在普通 Intel 处理器上大约是 5 到 8 秒。有点长，但对于一次加载的场景来说可以接受。如果你觉得太久，可以采用异步加载数据，配合 progress 回调提示用户，或者缩小初始数据量，后续再 updateDocument。

查询耗时：在 5 万条记录中搜索一个高频关键词，平均耗时在 10 到 20 毫秒之间。高频关键词意味着匹配结果很多，需要排序和截断，所以比低频词稍微慢一些。但无论如何，这个数字对于人机交互来说已经是完全无感知的级别。

内存占用：由于倒排索引的存在，大概比原始数据多占用 1.5 到 2 倍的内存。比如 10MB 原始文本，索引后大约要多占 15 到 20MB。这在 PC 上毫无压力，但如果你将来要做移动端低端机的搜索，就要留意一下这个内存增量。

作为对比，我同样用 Lunr.js 跑了一遍，初始化时间是 caveman 的三倍左右，查询时间两者接近。但如果把打包体积算进去，Lunr 核心要 30 多 KB，而 caveman 只有几 KB，差距非常明显。如果你的页面本身已经很大了，caveman 的这个体积优势相当可观。

3.4 search 方法的完整调用姿势

很多人以为 search 方法就是直接传一个字符串，其实它还支持传 options 覆盖初始化时的配置，这是非常灵活的一点。比如你的页面有两个不同的搜索入口，一个希望搜索标题时返回 5 条，另一个希望搜索全部内容时返回 50 条，可以直接在调用时指定，不需要创建两个引擎。

const titleResults = searchEngine.search('caveman', { limit: 5, keys: ['title'] }); const allResults = searchEngine.search('caveman', { limit: 50 });

这里要注意，覆盖的 options 是浅合并的，也就是说调用时传的 keys 会完全替代初始配置的 keys，而不是追加。如果你想在两个入口搜索不同字段，正确的做法是每次调用都传全量配置。

此外，search 方法的返回值是一个数组，默认数组元素就是原始记录对象。caveman 不会修改你的源对象字段，所以你可以放心地拿它做后续渲染和数据绑定。如果返回结果为空，那就是一个空数组，不需要额外判空逻辑。

4. 常见问题与排查技巧实录

4.1 为什么搜出来的结果总是“差两个字符”

有段时间很多用户反馈搜索“搜索”时，结果里有“搜索引擎”但排得很靠后，输“引擎”时又时灵时不灵。后来仔细排查发现，问题出在 threshold 默认值以及 token 的切分粒度上。默认 threshold 是 0.4，如果查询词比较短，比如两个字符，那么它要求匹配的字符比例就不容易满足；再加上默认 tokenizer 不处理中文，一个长句只能整段匹配，搜索“引擎”时可能匹配的是别的 token。

解决方式就是前面提的中文分词器，同时适当降低 threshold 到 0.3，或调高到 0.6 测试一下，看看你的语料下哪种更均衡。这里没有银弹，只能靠实测，我自己是 0.45 起步，结合数据反馈调整。

4.2 搜索结果过多导致页面卡顿

当搜索一个非常宽泛的词，比如“的”，如果数据里到处都是这个字，结果集可能达到几千条。即使 limit 限制了最终展示，但 caveman 内部在排序时仍然要处理所有匹配项，所以会有可感知的卡顿。

我的处理方案是两层防御。第一层靠 minChars 和 threshold 拦截，太短或太模糊的词直接不搜；第二层在调用 search 前对 query 做一次长度和非法字符校验，长度过短直接跳过搜索逻辑。这样至少能保证 UI 线程不会因为一个极端搜索词被长时间占用。

如果你确实需要支持“搜什么都要立刻返回”，那就必须考虑分页搜索了。每种搜索引擎都逃不过这个思路，caveman 也不例外——你可以在 search 结果上做数组 slice，也可以配合虚拟滚动列表，每次都只渲染前 50 条。

4.3 debug 模式怎么帮我定位问题

caveman 的 debug 选项我强烈建议在生产环境也保留一段时间，因为它输出的信息非常直观。每次调用 search 后，控制台会打印出查询词、内部生成的 token、匹配数量、耗时等数据。有一次我怀疑 updateDocument 没有生效，打开 debug 后看到索引里确实没出现新文档，这才发现问题出在数据更新时机上——我在 setData 前调用了 updateDocument，导致索引还没建起来就先加了文档，后面的 setData 又把这条覆盖了。

所以这里提醒大家，数据操作一定要分清楚时序：先 setData 建索引，再 updateDocument 更新，不能颠倒。否则会陷入“明明更新了却不生效”的困惑中。

4.4 常见问题速查表

这套速查表基本覆盖了大部分我遇到的真实问题，你也可以把它当作一个初始排查清单，有类似症状时逐条对照，能省下很多盲猜的时间。

4.5 避开两个容易踩的坑

第一个坑是所有字段混排搜索。如果你初始化时 keys 包含 content 这种长摘要字段，那么用户输入关键词时，所有含这个关键词的长文都会出现在结果里，而标题精确匹配的反而可能被淹没。我对策是最少保留两个搜索入口：一个只搜标题和标签，一个搜全文。前者用于站内快速跳转，后者用于深度检索，互不干扰。

第二个坑是忘记处理非法输入。比如用户在搜索框输入了空字符串、全是空格、或者重复特殊符号，如果不做拦截，caveman 依然会执行一轮搜索，返回的要么是空数组，要么是最靠前的几条记录，体验上非常怪异。我写了个轻量 helper，在搜索前统一 trim、过滤无意义字符，空内容直接返回空数组，不出意外的话能提升不少接口健壮性。

5. 实测对比：caveman、FlexSearch、Lunr.js 怎么选

5.1 三者的核心差异

FlexSearch 在性能上确实是同级别里的头部选手，它的内存占用和查询速度都很优秀，但它的 API 复杂度明显更高，你需要理解 series、cache、stemming 这些额外概念。Lunr.js 优点是生态成熟、功能全面、支持 pipeline，缺点也很明显——体积相对大，配置繁琐，对新手不太友好。caveman 算是两者之间的“极简派”，为了轻量做了一些牺牲，比如它没有复杂的语言分析器，没有开箱即用的多语言支持，但核心的搜索能力并没有缩水。

打个比方，FlexSearch 像是一台精密的高档跑车，功能强大但需要懂车才能开好；Lunr.js 像是一台功能丰富的房车，什么都能装但体积大；caveman 则像一辆手动挡的小钢炮，操控直接、反应灵敏，前提是你得接受它没有那些花哨的辅助系统。

5.2 什么情况下选 caveman 最明智

从我实际的使用经验出发，这几种情况我推荐 caveman：

• 项目是纯静态站点、没有后端服务，又不想为了搜索单独搞一个服务。
• 数据规模在几万条以内，不需要复杂分词和语义理解。
• 团队里没有人专门维护搜索服务，希望搜索模块代码量越少越好。
• 对首屏加载体积敏感，不希望引入一堆额外依赖。
• 你有能力自己写简单的分词逻辑，愿意对中文场景做定制开发。

反过来如果数据量达到百万级别，或者对多语言搜索、自然语言处理有硬性需求，那还是老老实实选重型方案。工具各有归位，看菜下饭才能避免后期踩坑。

5.3 一个让我意外的小细节：体积与调试成本

最后说一个让我意外的小细节。在优化项目打包体积时，我用构建工具拆包分析，发现 caveman 压缩后居然只有差不多一个 jQuery 插件的体积，而且它的源码可读性非常高，完全可以直接读源码排查逻辑。我遇到过一次排序顺序不对的问题，打开源码几百行里很快定位到 sort 处理的优先级。这种透明性在复杂库里面基本不可能实现，也算是给开发者省了不少调试成本。

6. 扩展应用：把 caveman 玩出更多花样

6.1 场景一：给表格加一个全字段筛选器

做过后台管理系统的肯定深有体会，表格数据一多，翻页找人就很难受。传统做法是后端模糊查询接口，但那需要每个表格都写一套接口。现在你可以把当前页面表格的所有行数据直接喂给 caveman，然后在前端做字段级筛选，查询毫秒级完成，后端完全不用改。

示例代码如下，我通常把整行数据对象化之后传给 searchEngine，然后在 keys 里配置所有需要搜索的列：

const tableData = [ { name: '张三', department: '研发部', serial: 'EMP-001' }, { name: '李四', department: '产品部', serial: 'EMP-002' } ]; searchEngine.setData(tableData); // 输入框每次触发 const results = searchEngine.search(keyword, { keys: ['name', 'department', 'serial'] });

这样一来，表格筛选和全文搜索的逻辑完全统一了，你只需要维护一份数据源。注意如果是大量表格行的场景，依然建议配合虚拟滚动使用。

6.2 场景二：实现输入联想与实时补全

caveman 天生适合做输入联想，因为它本身就是在一个轻量索引上进行实时匹配。你可以把已有的历史搜索词、常用标签、或者商品名存成一个数组，然后在用户输入时立刻搜索，并把结果以下拉层展示。

实现上需要注意体验细节：下拉层需要防抖，给用户留出输入停顿的时间；同时要标记键盘上下键的选择状态，支持回车直接选中。caveman 在这里只负责候选词召回，交互逻辑还是要自己写。我一般会把历史搜索词和实时索引结果做权重合并，历史搜索词优先展示，索引结果放在后面。

6.3 场景三：配合 Web Worker 做超大语料搜索

虽然几万条数据在前端跑没问题，但如果你的语料膨胀到几十万条，初始化时的耗时和内存占用就会让人有点紧张。这时可以把 caveman 丢进 Web Worker，在后台线程完成索引构建和查询，主线程只负责把结果渲染出来。

实现难度不大，核心就是把 searchEngine 实例放到 worker 脚本里，通过 postMessage 对外传递消息。主线程接收输入关键词后，用 postMessage 发送给 worker，worker 内部执行 search 后再把结果传回来。唯一要注意的就是 worker 环境下没有 window、document 这类 DOM API，caveman 本身不依赖这些，所以它能很好地跑在 worker 里。这种方式很适合那种需要秒开搜索能力、但首屏又不想被搜索初始化阻塞的重型工具站。

6.4 场景四：字段权重微调与自定义评分排序

caveman 默认的搜索结果排序是按内部匹配逻辑来的，但在实际业务里，标题命中的优先级通常会高于正文命中。虽然默认配置支持 keys 数组，但如果你想更精细化地控制权重，可以通过 sort 函数自己写一个评分规则。

我在某个知识库项目里的做法是：给每条记录临时附加一个 score 字段，标题命中的加 10 分，标签命中的加 6 分，正文命中的加 2 分，然后按 score 降序返回。

searchEngine.search(query, { keys: ['title', 'tags', 'content'], sort: (a, b) => (b._score || 0) - (a._score || 0) });

注意这里的 _score 字段需要你自己在预处理时塞进对象，或者用自定义 tokenizer 时对命中位置打分。caveman 本身不做高深的语义排序，所以这种灵活的自控能力反而是它最贴心的地方。

最后一个实用小技巧

我个人实际用下来最明显的体验就是：不要追求一个搜索库能解决所有搜索问题，caveman 的定位就是轻量、极简、快，你在选型时就要对应用场景有清醒认识。如果你做的是一个动辄几十万篇文章的知识库，还要做语义匹配、拼音纠错，那它确实不是最优选；但如果只是给自己的文档站、工具站、后台表格加一个搜索框，caveman 这套方案是我目前见过的“性价比”最高的选择之一。

最后再分享一个我一直在用的习惯：上线前用 debug 模式跑一轮典型关键词，记录每次的匹配数量和耗时，形成一份基线数据。之后每次改数据格式、调整参数，再跑一遍同一份关键词表对比数字，这样能很快发现哪些改动让搜索质量变差了。轻量工具的好处就是这些问题也都很轻量，很快就能定位到原因。希望这篇能让你少走些弯路，把搜索功能做得又快又省心。