Pagefind 静态搜索引擎

要解决的问题

静态站点越做越大之后，站内检索往往最先被牺牲掉。常见的搜索方案——无论是自建索引服务还是接入第三方搜索 API——都要引入后端进程、数据库或外部依赖：部署链路变长，原本「构建一次、随处托管」的静态站点被迫绑上服务端；每一次搜索请求还会消耗带宽、带来额外延迟，在移动网络或跨区域访问等低带宽、高延迟场景下尤其明显。对大量内容沉淀在静态页面上的站点来说，这个代价并不划算。

工作原理

Pagefind 选择的是另一条路：一个用 Rust 编写的静态搜索库，索引发生在站点构建完成之后，整个搜索链路不需要任何服务端组件。典型流程大致是：

• 站点正常构建，产出静态页面；
• 用 Pagefind 扫描构建产物，把页面内容整理成可检索的索引数据；
• 生成的搜索包作为纯静态资源随站点一起发布；
• 访问端加载该搜索包完成查询，请求不经过后端。

由于索引与查询都不依赖服务器，搜索功能可以直接落在 CDN、对象存储这类静态托管环境上；而低带宽的搜索包也让它适合内容量大、需要兼顾加载性能的站点。

适用边界与注意点

• 这是构建时索引方案，不负责处理实时更新：内容变更后需要重新构建并重新生成索引。
• 索引与搜索包的生成发生在构建阶段，超大站点的首次处理时间需要纳入 CI 预算。
• 该技能的 SKILL.md 未能自动提取出安装与使用说明，上游来源为第三方仓库 1991513ccie-png/skills；在敏感工作流中运行前，应先审阅上游项目再决定是否采用。