用 indexOf 实现轻量站内搜索需先对文本和关键词 trim() 和 toLowerCase()，遍历 DOM 节点匹配，replace 高亮前须转义正则特殊字符；matchAll 因返回含 index 的迭代器，比 match 更适合高亮与定位；input 事件配合防抖（clearTimeout + 合理延迟）可避免卡顿；静态小页面无需引入 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 处匹配”的前提。
使用场景：需要高亮多个关键词、统计总出现次数、或后续要做上下文提取（比如取匹配前/后 20 字）。
立即学习“前端免费学习笔记（深入）”；
- 必须加
g标志，否则matchAll不工作，返回空迭代器 - 正则需用
new RegExp(keyword, 'gi')构造，不能直接写字面量（否则无法动态插入变量） - IE 完全不支持
matchAll，如需兼容，得降级用循环 +indexOf+ 偏移量累加
input 事件里 debounce 怎么写才不卡顿
用户每敲一个键就触发全文扫描，DOM 量大时会明显卡顿，尤其在移动设备上。debounce 不是加个 setTimeout 就完事——关键在清除旧定时器、避免多次请求叠加、以及区分空搜索（清空结果）和有效搜索。
容易踩的坑：用 onkeyup 而不是 input，导致粘贴、语音输入、自动填充失效；或者 debounce 时间设成 300ms，但用户打字快时仍会漏触发。
- 监听
input事件，不是keyup - 每次触发先
clearTimeout上次的timerId，再设新定时器 - 输入为空字符串时，立即清空结果，不进 debounce 队列
- 推荐延迟值：中文输入法下建议 ≥ 500ms；英文可压到 250ms
为什么别急着引入 lunr.js 或 FlexSearch
这些库确实支持分词、权重、布尔查询，但体积大（lunr.js 压缩后仍 >15KB），初始化索引要遍历全部内容，首次搜索延迟明显。对于几百 KB 以内的静态 HTML，手写 indexOf + 缓存已够用，且可控性更强。
性能影响：FlexSearch 构建索引时会阻塞主线程，页面可能卡死 200–500ms；lunr 默认把所有文本塞进内存，移动端易 OOM。
- 只有当内容 >10MB 文本 或 需要拼音搜索、同义词扩展时，才值得引入
- 若真要用，务必预构建索引（服务端生成 JSON），而非浏览器端实时 parse HTML
- 注意
lunr的tokenizer默认不处理中文，需额外配lunr-chinese插件
搜索逻辑越靠近数据源，越容易出错——比如忘了排除 script、style 标签里的文本，或者高亮时把 HTML 标签当普通字符替换了。这些细节比选什么库更决定成败。
