indexOf 是最简站内搜索方案，适合静态页；需 trim() 和 toLowerCase() 预处理、遍历节点匹配、转义正则字符；matchAll 比 match 更适高亮因含位置信息；input 防抖须清定时器并区分空搜；内容少时无需 lunr.js 等重型库。
用 indexOf 做最简站内搜索，适合静态页
纯前端轻量搜索，indexOf 是最快上手的方式，适合内容固定、不常更新的静态页（比如文档页、帮助中心）。它不依赖任何库，兼容所有浏览器，但只支持子串匹配，不支持模糊、分词或大小写忽略。
常见错误现象：indexOf 返回 -1 却没做判断，导致搜索结果误显示“找到 0 处”；或直接拿用户输入去查，没做 trim() 和 toLowerCase()，搜“React” 找不到 “react”。
- 必须先对文本和关键词都调用
.trim().toLowerCase() - 遍历所有可搜索的 DOM 节点（如
article p、.content），逐段调用textContent.indexOf(keyword) - 匹配成功后，用
innerHTML.replace()高亮关键词时，注意转义正则特殊字符（.、*、(等）——否则会报错或漏匹配
matchAll 为什么比 match 更适合高亮
match 在全局模式下只返回匹配值数组，丢掉位置信息；而 matchAll 返回迭代器，每个结果带 index，能准确定位并包裹高亮标签。这是实现“搜索后滚动到第一个命中位置”或“显示第 X 处匹配”的前提。
- 必须加
g标志，否则matchAll不工作，返回空迭代器 - 正则需用
new RegExp(keyword, 'gi')构造，不能直接写字面量（否则无法动态插入变量） - IE 完全不支持
matchAll，如需兼容，得降级用循环 +indexOf+ 偏移量累加
input 事件里防抖怎么写才不卡顿
用户每敲一个键就触发全文扫描，DOM 量大时会明显卡顿，尤其在移动设备上。防抖不是加个 setTimeout 就完事——关键在清除旧定时器、避免多次请求叠加、以及区分空搜索（清空结果）和有效搜索。
立即学习“前端免费学习笔记（深入）”；
- 监听
input事件，不是keyup（否则粘贴、语音输入、自动填充失效） - 每次触发先
clearTimeout上次的timerId，再设新定时器 - 输入为空字符串时，立即清空结果，不进防抖队列
- 推荐延迟值：中文输入法下建议 ≥ 500ms；英文可压到 250ms
什么时候该放弃手写，改用 lunr.js 或 FlexSearch
这些库确实支持分词、权重、布尔查询，但体积大（lunr.js 压缩后仍 >15KB），初始化索引要遍历全部内容，首次搜索延迟明显。小页面硬上反而拖慢首屏。
真正需要它们的场景是：内容频繁更新、搜索词常含错别字、需按相关性排序、或支持 AND/OR 组合查询。否则，indexOf + matchAll + 合理防抖，已经覆盖 90% 的文档类页面需求。
容易被忽略的一点：高亮逻辑和 DOM 遍历本身没有“缓存友好性”，每次搜索都重扫全文。如果页面结构复杂、节点超千，哪怕用了防抖，首次命中前的卡顿感依然存在——这时不如把搜索入口放在折叠区域后，或提前预建轻量索引（比如只索引 h2 和 p 的首 200 字）。
