用javascript实现页面文本全局搜索需递归遍历dom，过滤文本节点（nodetype===3），跳过script/style/textarea/input等非展示节点；匹配关键词后用range和mark元素包裹，避免innerhtml替换破坏事件绑定；支持上下跳转需首次缓存所有匹配位置（节点+偏移量），高亮时切换active类并滚动聚焦；移动端需加tabindex="-1"和focus()，无障碍需role="note"及aria-label，慎用smooth滚动。
怎么用 JavaScript 实现页面内文本全局搜索
直接在 DOM 中遍历所有文本节点，用 textContent 匹配关键词，再高亮匹配部分——这是最可控、兼容性最好、不依赖第三方库的做法。别想着靠浏览器自带的 Ctrl+F，它不支持编程控制、无法自定义样式、也不能限定搜索范围。
核心思路是：递归遍历 document.body 下所有节点 → 过滤出文本节点（nodeType === 3）→ 对每个文本节点执行 String.prototype.indexOf() 或正则匹配 → 找到后用 Range 和 document.createElement('mark') 包裹匹配内容。
- 必须跳过
script、style、textarea、input等非展示型节点，否则会误搜代码或表单值 - 搜索前建议先清除上次的
<mark></mark>，否则重复搜索会嵌套标签，导致样式错乱或 DOM 泄漏 - 大小写敏感与否由
new RegExp(keyword, 'g')的标志控制，推荐默认加i标志，用户更习惯不区分大小写
为什么不能直接用 innerHTML.replace() 替换全文本
因为 innerHTML 是字符串，替换后会丢失所有事件监听器、Vue/React 绑定、动态生成的内容结构，甚至可能破坏 HTML 语法（比如把 <div class="test"> 里的 <code>class 当成关键词替换了）。真实项目里一刷新就丢交互，得不偿失。
正确做法是只操作文本节点本身，用 splitText() 切分节点，再插入 <mark></mark> 元素——这样既保留原始 DOM 结构，又不影响绑定逻辑。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 错误示例：
document.body.innerHTML = document.body.innerHTML.replace(/foo/g, '<mark>foo</mark>') - 正确路径：获取
Text节点 →node.splitText(offset)→parent.insertBefore(markEl, nextNode) - 注意
splitText()会改变后续节点索引，循环时建议倒序处理或缓存匹配位置再批量操作
如何支持“下一个/上一个”跳转和计数显示
关键不是反复搜索 DOM，而是首次搜索时就缓存所有匹配位置（Range 对象或 DOM 节点 + 偏移量），之后通过索引切换高亮状态。每次跳转只需 range.selectNodeContents(textNode) 再 window.getSelection().removeAllRanges(); window.getSelection().addRange(range) 即可滚动并聚焦。
- 缓存结构建议用数组：
const matches = [{ node, offset, length }, ...] - 高亮当前项时，先移除所有
<mark></mark>的class="active"，再给当前<mark></mark>加上 - 计数显示直接用
matches.length和当前索引（从 0 开始），注意索引越界要取模或禁用按钮 - 如果页面有 iframe，需单独访问其
contentDocument，但跨域 iframe 无法读取，得提前判断
移动端和无障碍支持要注意什么
触摸设备上点击 <mark></mark> 不会自动触发 focus，导致键盘导航失效；屏幕阅读器默认不朗读 <mark></mark> 的语义。这两个问题必须手动补救。
- 给每个
<mark></mark>加tabindex="-1"，并在点击后调用.focus()，让键盘能按 Tab 键顺序到达 - 加上
role="note"和aria-label（例如aria-label="搜索结果第2处"），辅助技术才能识别这是搜索命中项 - 避免用纯背景色高亮（如黄色底），至少叠加文字描边或阴影，否则色弱用户可能完全看不见
- 不要用
scrollIntoView({ behavior: 'smooth' })在低端 Android 上，容易卡死，降级为scrollIntoView()更稳妥
搜索逻辑本身很简单，难的是边界情况：iframe、富文本编辑器、Shadow DOM、动态加载内容。这些地方要么预埋钩子，要么监听 MutationObserver，但别一上来就搞太重——先跑通主文档，再按需扩展。
