1. 从一次抓狂的页面搜索说起
你有没有遇到过这种情况：在一个技术文档页面或者后台管理系统的表格里，明明肉眼看到某个字段写的是UserName，结果按 Ctrl+F 搜username，浏览器告诉你"找不到匹配项"。你只能一遍遍调整大小写，或者干脆放弃搜索，用眼睛一行行扫。这种体验在数据量大的页面上尤其让人崩溃。
浏览器原生的查找功能默认是区分大小写的，而且它不提供任何开关让你切换。对于普通用户来说，这也许只是个小不便；但对于每天要跟大量代码、日志、配置项打交道的开发者来说，这就是一个实打实的效率杀手。更麻烦的是，很多在线工具类网站（比如 JSON 格式化、代码对比、日志分析面板）内部渲染的内容，浏览器原生搜索有时候还会漏掉动态加载的部分。
那有没有办法让浏览器搜索变得"聪明"一点，自动忽略大小写？有。而且不需要装任何插件，不需要改浏览器源码，只需要给浏览器加一个自定义的 JavaScript 标签——也就是我们常说的"书签小工具"（Bookmarklet），就能实现页面内的大小写不敏感搜索。这篇文章就把我实际折腾这套方案的完整过程拆开来讲，从原理到代码，从踩坑到优化，全部摊开说清楚。
提示：本文讨论的是在浏览器中通过自定义脚本增强页面搜索体验，所有操作均在浏览器正常功能范围内，不涉及任何绕过安全机制的行为。
2. 为什么浏览器原生搜索不做大小写忽略
2.1 原生查找的设计取舍
浏览器原生查找功能（Ctrl+F）的核心目标是"精确匹配"。它的实现逻辑是在页面的文本节点中做字符串比对，默认采用区分大小写的模式。这个设计本身没有错——在代码审查、配置文件核对等场景下，Name和name确实是两个不同的东西，精确匹配反而更安全。
但问题在于，浏览器没有给用户一个切换开关。对比一下，很多桌面端的编辑器（比如 VS Code、Sublime Text）都提供了"区分大小写"的勾选框，用户可以根据场景自由切换。浏览器把这个选择权拿掉了，只保留了最严格的模式。
2.2 动态渲染内容的搜索盲区
另一个容易被忽略的问题是：浏览器原生搜索只能匹配当前 DOM 中已经存在的文本。如果页面是通过前端框架（React、Vue 等）动态渲染的，而且内容是在用户滚动时才懒加载的，那么原生搜索很可能找不到那些还没渲染出来的部分。这就导致了一个尴尬的局面——你明明知道页面上有某个关键词，但搜索就是搜不到。
自定义 JS 标签的方案，恰好可以同时解决这两个问题：一方面通过脚本实现大小写不敏感的匹配逻辑，另一方面可以在脚本中主动触发页面的内容加载或遍历所有已渲染的文本节点。
2.3 书签小工具的天然优势
书签小工具的本质是一段以javascript:开头的 URL，当你点击这个书签时，浏览器会在当前页面上下文中执行这段脚本。它不需要安装扩展、不需要重启浏览器、不占用后台资源，用完即走。对于"偶尔需要增强搜索"这个需求来说，书签小工具是最轻量的方案。
当然，它也有局限性——比如无法跨页面持久化状态、无法访问某些受保护的浏览器 API。但对于页面内搜索这个场景来说，这些限制都不构成障碍。
3. 核心思路：用脚本接管页面搜索
3.1 整体方案设计
要实现大小写不敏感的页面搜索，核心逻辑可以拆成三步：
- 获取用户输入的关键词：通过
prompt弹窗让用户输入要搜索的内容。 - 遍历页面文本节点：用
TreeWalker或递归遍历的方式，找到所有包含目标关键词的文本节点。 - 高亮并定位匹配项：将匹配到的文本用
<mark>标签包裹，并滚动到第一个匹配位置。
这个思路听起来简单，但实际写起来有几个关键决策点需要仔细考虑。
3.2 为什么选 TreeWalker 而不是 innerHTML 替换
很多人第一反应可能是：直接把document.body.innerHTML拿出来，用正则替换不就行了？这个做法在简单页面上确实能跑通，但在真实场景中会引发灾难性问题。
innerHTML替换会破坏页面原有的 DOM 结构和事件绑定。举个例子，如果页面上有个按钮绑定了点击事件，你替换innerHTML之后，按钮虽然看起来还在，但事件监听器已经丢失了，点击没反应。更严重的是，如果页面用了前端框架，框架内部的虚拟 DOM 和真实 DOM 之间的引用关系会被打乱，可能导致页面直接崩溃。
TreeWalker则是浏览器原生提供的 DOM 遍历 API，它只读取文本节点，不修改结构，安全性高得多。具体来说，我们用document.createTreeWalker创建一个遍历器，过滤出所有NodeFilter.SHOW_TEXT类型的节点，然后逐个检查文本内容。
3.3 高亮方案的选择
找到匹配的文本节点后，需要把匹配部分高亮出来。这里有两种做法：
- 方案一：直接修改文本节点的
nodeValue，把匹配部分替换成带<mark>标签的 HTML。但文本节点的nodeValue是纯文本，不能直接插入 HTML 标签。 - 方案二：创建一个新的
<mark>元素，把匹配的文本放进去，然后用replaceChild替换原来的文本节点。如果匹配文本只是节点内容的一部分，还需要把原节点拆分成"匹配前""匹配项""匹配后"三段。
方案二是标准做法，虽然代码稍复杂，但不会破坏页面结构。实际实现时，我会把匹配到的文本节点收集到一个数组里，然后倒序处理（从后往前替换），这样就不会因为节点拆分导致索引错乱。
3.4 大小写不敏感的实现细节
大小写不敏感的核心就是把两边都转成小写再比较。但这里有个细节：转小写之后，匹配位置的长度可能和原文不一致。比如德语中的ß转小写还是ß，但某些特殊字符转换后长度会变。对于绝大多数中文和英文场景来说，这个问题可以忽略，但如果你要处理多语言内容，建议用toLowerCase()之后再用indexOf定位，然后按原始字符串的长度来截取。
另外，如果用户输入的关键词包含正则特殊字符（比如.、*、(等），直接构造正则表达式会出错。所以要么对特殊字符做转义，要么干脆用indexOf做纯字符串匹配。我倾向于后者，因为更简单、更可控。
4. 完整代码实现与逐段拆解
4.1 书签小工具的代码结构
下面是我实际在用的完整代码。为了方便你直接复制使用，我把它压缩成了一行，但这里先展开写，方便逐段讲解。
(function() { // 第一步：获取搜索关键词 var keyword = prompt('请输入搜索关键词（不区分大小写）：'); if (!keyword || keyword.trim() === '') return; keyword = keyword.trim().toLowerCase(); // 第二步：清除上一次的高亮 var existingMarks = document.querySelectorAll('mark[data-custom-search]'); for (var i = 0; i < existingMarks.length; i++) { var mark = existingMarks[i]; var parent = mark.parentNode; parent.replaceChild(document.createTextNode(mark.textContent), mark); parent.normalize(); } // 第三步：遍历所有文本节点 var walker = document.createTreeWalker( document.body, NodeFilter.SHOW_TEXT, { acceptNode: function(node) { // 跳过 script、style、textarea 等不可见内容 var tag = node.parentNode.tagName.toLowerCase(); if (tag === 'script' || tag === 'style' || tag === 'textarea' || tag === 'noscript') { return NodeFilter.FILTER_REJECT; } // 跳过已经高亮的节点 if (node.parentNode.tagName.toLowerCase() === 'mark') { return NodeFilter.FILTER_REJECT; } return NodeFilter.FILTER_ACCEPT; } } ); var textNodes = []; var node; while (node = walker.nextNode()) { if (node.nodeValue.toLowerCase().indexOf(keyword) !== -1) { textNodes.push(node); } } if (textNodes.length === 0) { alert('未找到匹配内容'); return; } // 第四步：倒序处理，避免节点拆分后索引错乱 var firstMark = null; for (var j = textNodes.length - 1; j >= 0; j--) { var textNode = textNodes[j]; var text = textNode.nodeValue; var lowerText = text.toLowerCase(); var fragments = []; var lastIndex = 0; var matchIndex; while ((matchIndex = lowerText.indexOf(keyword, lastIndex)) !== -1) { // 匹配项之前的文本 if (matchIndex > lastIndex) { fragments.push(document.createTextNode(text.substring(lastIndex, matchIndex))); } // 匹配项本身 var markEl = document.createElement('mark'); markEl.setAttribute('data-custom-search', 'true'); markEl.style.backgroundColor = '#ffeb3b'; markEl.style.color = '#000'; markEl.textContent = text.substring(matchIndex, matchIndex + keyword.length); fragments.push(markEl); if (!firstMark) firstMark = markEl; lastIndex = matchIndex + keyword.length; } // 剩余文本 if (lastIndex < text.length) { fragments.push(document.createTextNode(text.substring(lastIndex))); } // 用文档片段替换原文本节点 var fragment = document.createDocumentFragment(); for (var k = 0; k < fragments.length; k++) { fragment.appendChild(fragments[k]); } textNode.parentNode.replaceChild(fragment, textNode); } // 第五步：滚动到第一个匹配项 if (firstMark) { firstMark.scrollIntoView({ behavior: 'smooth', block: 'center' }); } // 输出匹配数量 var totalMarks = document.querySelectorAll('mark[data-custom-search]').length; console.log('共找到 ' + totalMarks + ' 处匹配'); })();4.2 关键步骤的意图说明
清除上一次高亮这一步很多人会忽略。如果你连续搜索两次，第一次的高亮还在页面上，第二次搜索时那些<mark>标签里的文本也会被遍历到，导致重复高亮或者匹配数量虚高。所以每次执行前先把之前插入的<mark>还原成普通文本节点，并用normalize()合并相邻的文本节点。
过滤不可见内容也很重要。<script>和<style>标签里的内容虽然也是文本节点，但它们不会显示在页面上，搜索它们没有意义，还会拖慢速度。<textarea>里的内容虽然可见，但它是表单控件，修改它的文本节点会破坏用户输入，所以也要跳过。
倒序处理是避免索引错乱的关键。假设一个文本节点里有三处匹配，你从前往后替换，第一处替换后节点被拆分了，后面两处的索引就全乱了。从后往前处理，前面的节点位置不受影响。
滚动定位用scrollIntoView把第一个匹配项滚到视口中间，这样用户一眼就能看到搜索结果。加上behavior: 'smooth'让滚动更自然。
4.3 如何把它变成书签
把上面这段代码压缩成一行（去掉换行和多余空格），然后在前面加上javascript:，就得到了书签的 URL。具体操作：
- 在浏览器书签栏上右键，选择"添加新书签"。
- 名称随便写，比如"大小写搜索"。
- URL 粘贴压缩后的代码，确保以
javascript:开头。 - 保存。
以后在任何页面点击这个书签，就会弹出输入框，输入关键词后自动高亮所有匹配项（不区分大小写）。
注意：部分浏览器在粘贴
javascript:开头的 URL 时会自动去掉前缀，需要手动补上。另外，某些网站的内容安全策略（CSP）可能会阻止书签脚本执行，这种情况下脚本会静默失败，不会报错。
5. 实测中遇到的坑与修复过程
5.1 高亮后页面样式错乱
第一次测试时，我在一个后台管理页面上搜索"id"，结果页面布局直接崩了。排查后发现，那个页面用了大量的<span>和<div>做精细排版，我的脚本把匹配到的文本节点替换成了<mark>元素，而<mark>默认是行内元素，但带有浏览器默认样式（黄色背景），在某些 flex 布局中会导致换行或宽度变化。
修复方案是给<mark>加上display: inline和background-color的显式设置，同时避免修改其他样式属性。如果页面本身对行内元素有特殊样式要求，可以考虑用<span>加自定义 class 代替<mark>，这样对布局的影响更小。
5.2 搜索速度慢的问题
在一个包含上万行日志的页面上测试时，脚本执行了将近 3 秒才出结果。主要耗时在TreeWalker遍历和字符串比较上。优化思路有两个：
- 限制遍历范围：如果页面有明显的"主内容区"（比如
<main>或<article>），可以只遍历那个区域，而不是整个document.body。 - 提前终止：如果匹配数量已经超过某个阈值（比如 500 个），可以停止继续遍历，避免无意义的性能消耗。
我在实际使用中加了一个简单的判断：如果textNodes.length超过 1000，就只处理前 1000 个，并在控制台提示"匹配项过多，仅显示前 1000 个"。
5.3 特殊字符导致的匹配失败
有一次搜索C++，结果什么都搜不到。原因是+在正则中是特殊字符，虽然我用的是indexOf而不是正则，但问题出在另一个地方——页面上显示的是C++，但实际 DOM 中可能是C<span>+</span><span>+</span>这样的结构，文本被拆分到了多个节点里。
这种跨节点的匹配是TreeWalker方案的天然短板。要彻底解决，需要把相邻的文本节点合并后再匹配，但实现复杂度会大幅上升。对于大多数场景来说，这个问题出现的概率不高，我个人的做法是接受这个限制，遇到跨节点的情况就手动调整搜索词。
5.4 与页面自身快捷键的冲突
有些网站（比如在线代码编辑器）会监听键盘事件，我的书签脚本本身不涉及键盘监听，所以不存在冲突。但如果你把书签脚本改造成通过快捷键触发，就要注意不要覆盖页面原有的快捷键。建议用Ctrl+Shift+F这种组合，冲突概率较低。
5.5 动态加载内容的处理
对于懒加载的页面，脚本只能搜索当前已经渲染的内容。如果你需要搜索全部内容，可以先手动滚动到页面底部触发加载，然后再执行搜索。或者，在脚本中加入自动滚动的逻辑——先滚到底部，等几秒让内容加载完，再滚回顶部执行搜索。这个方案我试过，在大多数页面上可行，但会增加脚本的等待时间，体验上不够流畅，所以最终没有集成到主流程里。
6. 进阶玩法：让搜索更贴合个人习惯
6.1 记住上一次的搜索词
每次都要重新输入关键词确实有点烦。可以利用localStorage把上一次的搜索词存下来，下次执行时作为prompt的默认值。代码改动很小：
var lastKeyword = localStorage.getItem('customSearchLast') || ''; var keyword = prompt('请输入搜索关键词（不区分大小写）：', lastKeyword); if (!keyword || keyword.trim() === '') return; localStorage.setItem('customSearchLast', keyword.trim());这样下次打开搜索框时，上次的词已经填好了，直接回车就行。
6.2 支持多个关键词同时高亮
有时候你想同时找"error"和"warning"，用不同颜色标出来。这个需求可以通过把关键词按空格拆分，然后分别用不同的背景色高亮来实现。核心逻辑不变，只是把单关键词匹配改成循环处理多个关键词，每个关键词分配一个颜色。
颜色分配可以用一个预设的数组，比如['#ffeb3b', '#ff9800', '#4caf50', '#2196f3']，按顺序取用。注意不同关键词的高亮要分别用不同的data属性标记，方便清除。
6.3 统计匹配数量并展示
在页面右上角浮出一个小的统计面板，显示"共找到 X 处匹配"，比在控制台输出更直观。实现方式是在页面上动态创建一个固定定位的div，设置好样式后插入document.body。搜索完成后更新它的文本内容，几秒后自动消失。
这个面板的样式要注意不要被页面的全局 CSS 影响，建议用内联样式或者!important覆盖。另外，面板的z-index要设得足够高，避免被页面其他元素遮挡。
6.4 适配暗色主题
很多开发者习惯用暗色主题，默认的黄色高亮在暗色背景上非常刺眼。可以根据页面的背景色自动调整高亮颜色——如果页面背景是深色，就用深色系的高亮（比如深蓝底白字）；如果是浅色，就用传统的黄底黑字。
判断页面背景色可以通过getComputedStyle(document.body).backgroundColor获取，然后解析 RGB 值计算亮度。亮度低于某个阈值就认为是暗色主题。这个逻辑不复杂，但能显著提升使用体验。
6.5 把脚本做成可配置的
如果你愿意多花点时间，可以把脚本改造成从 URL 参数读取配置的形式。比如书签 URL 写成javascript:(function(){...})()的形式，然后在脚本内部读取location.hash或location.search中的参数来决定高亮颜色、是否滚动、是否统计数量等行为。这样你可以创建多个书签，分别对应不同的搜索模式，灵活性更高。
7. 一些实操心得和边界说明
这套方案我用了大半年，在技术文档、后台系统、日志面板等各种页面上都测试过，整体稳定性不错。但有几点需要提前说清楚，避免你在使用过程中产生误解。
第一，它不能替代浏览器的原生搜索。原生搜索有它的优势——支持回车跳转下一个匹配项、支持搜索框实时预览、支持跨 iframe 搜索。我的脚本只做了一件事：把匹配项高亮出来并滚动到第一个位置。如果你需要逐个跳转匹配项，还是得用原生搜索，或者把脚本进一步改造成支持"下一个/上一个"导航的形式。
第二，它对跨节点文本无能为力。前面提到过，如果一个词被 HTML 标签拆散了，脚本就找不到。这是TreeWalker方案的固有局限，除非引入更复杂的文本合并逻辑，否则无法根治。
第三，部分网站会阻止脚本执行。内容安全策略（CSP）严格的网站，比如一些银行和支付页面，会禁止javascript:协议的书签脚本运行。这种情况下脚本不会有任何反应，也不会报错，你只能换其他方式。
第四，高亮后的页面如果发生动态更新，高亮可能会丢失。比如在一个实时刷新的数据面板上，你高亮了某些内容，几秒后数据更新，DOM 被重新渲染，高亮就没了。这是正常现象，重新执行一次搜索即可。
第五，代码要定期检查更新。浏览器的 API 虽然稳定，但偶尔会有废弃和变更。比如document.createTreeWalker的某些参数在旧版本浏览器中行为不一致。建议每隔几个月重新测试一下脚本，确保在新版浏览器中仍然正常工作。
最后分享一个我个人的小习惯：我会把这个书签放在书签栏最左侧，方便快速点击。同时给它设了一个容易记的快捷键（通过浏览器的书签管理器设置），需要搜索时直接按快捷键，比用鼠标点快得多。这个组合用熟了之后，页面搜索的效率提升非常明显，尤其是那些需要反复核对大小写字段的场景，再也不用一遍遍手动调整搜索词了。
