静态站搜索的三种做法，以及它们各自真实的上限

XIAOXUsop — Fri, 14 Aug 2026 00:00:00 GMT

静态站没有后端，所以搜索必须换个地方放。只有三个位置：

放进浏览器、放进构建产物、放到另一台服务器上。

选哪种，取决于你愿意接受哪一种上限。

一、放进浏览器：把内容全量打到前端#

最简单：构建时把全部文章导成一个 JSON，页面加载后在前端过滤。

const results = all.filter(p => p.title.includes(q) || p.body.includes(q));

上限在「全量」两个字上。 索引就是全部正文，文章一多，用户为了搜一个词要下载整站内容。

50 篇中等长度的文章大约 1–2 MB。1000 篇就是几十 MB——搜索框还没用上，流量已经烧完了。

它适合几十篇以内的站点。超过这个量级，你会开始想「能不能只加载摘要」，而那正是第二种方案。

构建时切词、建倒排索引，把索引作为静态资源发布。用户只下载索引，不下载正文；命中之后再按需取片段。

这一类的代表是 Pagefind 和 Fuse.js：

Pages/Netlify 这类托管上，Pagefind 是当前最省事的选择：一条命令，零后端，还能按语言分别处理。

上限在分词上。

Pagefind 对中文不做词干提取——中文本来也没有词形变化，所以这不影响正确性。真正的影响是召回：它按字/词切分建索引，你搜「排版」能命中包含「排版」的段落，但搜「网页排版」不一定能命中只写了「排版」的地方。

英文靠词干回退（running ↔ run）缓解这类问题，中文没有对应机制。 这是静态站搜索的固有限制，不是某个库的缺陷。

把索引放到一台真的服务器上，查询走网络。

功能上限最高：分词器可换、同义词、拼写纠错、按字段加权、结果高亮、搜索分析——都能做。

代价也很清楚：

它适合「搜索是核心功能」的站点——文档站、电商、知识库。对个人博客，通常是过度配置。

判断的关键不是功能表，是「索引存在哪」：在用户浏览器里、在构建产物里、还是在别人的服务器上。三种位置对应三种上限，没有例外。

前两种方案都跑在浏览器里，所以没有 JS 就没有搜索。

这不是可以糊弄过去的——正确的做法是给一个 <noscript> 出口，让关掉 JS 的读者至少能走到归档页，而不是对着一个永远转圈的输入框。

Pagefind 官方文档（索引分片与多语言处理）
Fuse.js 官方文档（模糊匹配算法与阈值）
本文提到的中文召回限制来自本站在 2026-09 的实测：搜「排版」7 条命中，搜「行高」6 条命中，而搜「网页排版」只有 4 条——少掉的那几条正是正文里只写了「排版」、没写完整四个字的地方

复现方式：npm run build 之后到 /search/ 搜这三个词。 npm run dev 里搜不到任何东西——索引是构建期（Pagefind）生成的，开发服务器没有它。这个数字也会随内容增删而变化，上面记的是当时的快照。