尧图网站建设 
简介Super Highlight 是一款面向浏览器用户的文本高亮插件可视为 Multi-highlight 的升级版本主要解决长文档、文献与网页信息中关键词难以快速定位的问题适合学术研究、资料整理及日常阅读场景使用。资源包共 13 个文件约 131KB以 6 个 js 脚本为核心承载高亮算法与交互逻辑另含 1 个 html 弹窗界面、1 个 json 配置文件、1 个 css 样式表及 4 个 png 图标资源结构紧凑、便于直接加载调试。插件在原有基础上优化了文本输入布局并引入关键词分类固定颜色与分类独立开关用户可按人名、日期、概念等类别设定专属颜色并单独控制各类高亮显示从而提升信息识别与处理效率。目前已有 393 人学习下载适合希望研究浏览器扩展实现方式或需要高效标注文本的读者参考借鉴。1. 从“Super highlight.zip”说起一个高亮方案到底在解决什么如果你在代码托管平台搜过“Super highlight.zip”大概率会看到一堆同名压缩包解压后是几个 CSS、JS 和一份 README。它不是一个官方库更像是一类“高亮增强方案”的统称——把代码块、搜索结果、日志行、表格选中项这些需要被视觉拎出来的内容做得比浏览器默认的mark更可控。真正让人头疼的不是“怎么变黄”而是高亮之后长代码块里高亮错位、暗色主题下对比度崩掉、动态渲染的内容高亮丢失、移动端选中高亮拖尾。这些才是搜索“Super highlight.zip”的人真正想解决的问题。这篇笔记面向需要在前端或文档站里落地高亮能力的工程师从选型、最小实现、参数调优到排错把这条路走通。2. 高亮方案选型为什么不是直接写 background-color2.1 三种主流实现路径的边界在动手之前先把“高亮”这件事拆开。它至少有三个层次静态文本标记、动态范围标记、语义化高亮。静态文本标记就是给一段文字套mark或span classhl改背景色和文字色动态范围标记用Range和SelectionAPI处理用户选中、搜索命中、编辑器内联高亮语义化高亮则要区分“命中关键词”“当前激活项”“上下文预览”等不同状态每种状态有独立的视觉权重。常见做法有三条路。第一条是纯 CSS 类名方案适合服务端渲染好的静态内容成本最低但遇到动态插入的节点就失效。第二条是CSS Custom Highlight API浏览器原生支持把任意Range注册成高亮不污染 DOM适合搜索命中和编辑器场景但兼容性需要确认。第三条是包裹 DOM 节点用span把目标文本包起来再加类名兼容性最好代价是频繁操作 DOM长文档下性能会抖。我一般会先问一句高亮的内容会不会变如果不会变CSS 类名足够如果会随输入、滚动、搜索变化优先考虑 Custom Highlight API如果必须兼容老浏览器再退回 DOM 包裹但要加防抖和范围合并。2.2 最小可运行的高亮实现下面这段代码用CSS Custom Highlight API做一个搜索命中高亮的最小闭环。它不修改 DOM只把匹配到的文本范围注册成高亮。// 检查浏览器是否支持 Custom Highlight API if (!CSS.highlights) { console.warn(当前环境不支持 CSS Custom Highlight API需降级到 DOM 包裹方案); } // 在指定容器内搜索关键词并注册高亮 function highlightKeyword(container, keyword) { // 先清空旧高亮避免叠加 CSS.highlights.clear(); const walker document.createTreeWalker( container, NodeFilter.SHOW_TEXT, null ); const ranges []; let node; while ((node walker.nextNode())) { const text node.textContent; const lowerText text.toLowerCase(); const lowerKeyword keyword.toLowerCase(); let index lowerText.indexOf(lowerKeyword); while (index ! -1) { const range new Range(); range.setStart(node, index); range.setEnd(node, index keyword.length); ranges.push(range); index lowerText.indexOf(lowerKeyword, index keyword.length); } } if (ranges.length 0) { // 注册一个名为 search-hit 的高亮 const highlight new Highlight(...ranges); CSS.highlights.set(search-hit, highlight); } return ranges.length; } // 调用示例 const article document.querySelector(#article); const count highlightKeyword(article, 高亮); console.log(命中 ${count} 处);逻辑说明TreeWalker遍历容器内所有文本节点逐个查找关键词位置用Range精确圈出每一处命中。CSS.highlights.set把一组 Range 注册成命名高亮浏览器负责绘制不插入任何额外节点。参数说明container是搜索范围根节点建议限定在正文区域避免把导航和页脚也扫进去keyword是搜索词大小写不敏感处理在代码里已经做了CSS.highlights.clear()每次调用前清空防止多次搜索后高亮叠加。配套 CSS 只需要一行::highlight(search-hit) { background-color: #ffe066; color: #1a1a1a; }暗色主题下把background-color换成低饱和的#5c4d1f文字色换成#f5f5f5对比度才够。不要直接用纯黄配纯白那是血泪经验看十分钟眼睛就酸。2.3 降级方案DOM 包裹的边界控制如果目标环境不支持 Custom Highlight API就得退回 DOM 包裹。核心思路是把文本节点拆开在命中位置插入mark节点。这里有两个必须控制的参数单次处理的最大文本长度和最大命中数。超过阈值就分片处理否则长文档会卡死主线程。function wrapHighlight(container, keyword, maxHits 500) { const walker document.createTreeWalker(container, NodeFilter.SHOW_TEXT, null); const textNodes []; let node; while ((node walker.nextNode())) { if (node.textContent.toLowerCase().includes(keyword.toLowerCase())) { textNodes.push(node); } } let hitCount 0; for (const textNode of textNodes) { if (hitCount maxHits) break; const text textNode.textContent; const lowerText text.toLowerCase(); const lowerKeyword keyword.toLowerCase(); const fragment document.createDocumentFragment(); let lastIndex 0; let index lowerText.indexOf(lowerKeyword); while (index ! -1 hitCount maxHits) { // 命中前的普通文本 fragment.appendChild(document.createTextNode(text.slice(lastIndex, index))); // 命中部分用 mark 包裹 const mark document.createElement(mark); mark.className hl-hit; mark.textContent text.slice(index, index keyword.length); fragment.appendChild(mark); lastIndex index keyword.length; hitCount; index lowerText.indexOf(lowerKeyword, lastIndex); } // 剩余文本 fragment.appendChild(document.createTextNode(text.slice(lastIndex))); textNode.parentNode.replaceChild(fragment, textNode); } return hitCount; }逻辑说明先把所有包含关键词的文本节点收集起来再逐个替换。DocumentFragment减少真实 DOM 操作次数。参数说明maxHits默认 500超过就停止防止一次搜索把整页拆成几万个节点实际项目里可以配合requestIdleCallback分片执行每帧只处理 50 个节点。注意包裹后的mark节点如果再次被搜索命中会被重复包裹所以每次重新搜索前要先还原原始文本或者用>function setActiveHit(ranges, activeIndex) { if (!ranges.length) return; // 普通命中全部注册 CSS.highlights.set(search-hit, new Highlight(...ranges)); // 当前项单独注册优先级更高 const activeRange ranges[activeIndex]; if (activeRange) { CSS.highlights.set(search-active, new Highlight(activeRange)); // 滚动到当前项 const rect activeRange.getBoundingClientRect(); if (rect.top 0 || rect.bottom window.innerHeight) { activeRange.startContainer.parentElement.scrollIntoView({ block: center, behavior: smooth }); } } }逻辑说明search-hit承载所有命中search-active只承载当前项。CSS 里::highlight(search-active)的优先级天然高于::highlight(search-hit)不需要额外处理。参数说明activeIndex是当前命中在数组里的下标切换时只改这一个值避免全量重绘。注意getBoundingClientRect对 Range 调用时如果 Range 跨多个行盒返回的是第一个行盒的位置长文本换行时滚动定位可能偏上需要额外判断。3.3 性能边界多少命中量会开始卡Custom Highlight API 的性能远好于 DOM 包裹但也不是无限。实测在 5000 个 Range 以内注册和绘制都在 16ms 内完成超过 1 万个 Range首次注册会掉到 30ms 以上滚动时偶发掉帧。DOM 包裹方案在 2000 个节点左右开始明显卡顿因为每次插入mark都会触发样式重算。所以参数上我一般这样定Custom Highlight API 单次最多注册 8000 个 Range超过就只高亮可视区域内的命中DOM 包裹方案单次最多 500 个超过就提示用户缩小搜索范围。可视区域高亮需要监听滚动动态增删 Range复杂度更高但长文档场景下是唯一可行的路。4. 避坑与排查高亮方案落地时的五个翻车现场4.1 高亮错位Range 偏移了一个字符现象搜索“高亮”时高亮区域从第二个字开始或者多高亮了一个字符。原因通常是Range.setStart的 offset 算错了。TreeWalker返回的文本节点里如果包含 HTML 实体比如amp;textContent的长度和源码长度不一致但Range的 offset 是基于textContent的所以只要统一用textContent计算就不会错。真正容易错的是先对textContent做了trim()或toLowerCase()之后用处理后的字符串下标去设 Range长度变了偏移就错了。解决所有下标计算都在原始textContent上进行大小写比较用toLowerCase()的副本但下标取自原始字符串。4.2 暗色主题下高亮“消失”现象切换暗色主题后高亮区域几乎看不见。原因CSS 里只定义了亮色主题的::highlight样式暗色主题下背景色和文字色对比度不足。解决用prefers-color-scheme或主题类名分别定义两套高亮样式暗色下背景色亮度降低、文字色提亮。不要指望浏览器自动反色。4.3 动态内容高亮丢失现象搜索结果加载后高亮正常但用户滚动加载更多内容后新内容没有高亮。原因高亮只在初始 DOM 上执行了一次新插入的节点没有被TreeWalker扫到。解决用MutationObserver监听容器变化新增节点时增量执行高亮而不是全量重跑。增量时注意合并相邻 Range避免碎片化。4.4 高亮与用户选中冲突现象用户手动选中一段文字时浏览器默认的选中高亮和自定义高亮叠在一起颜色混乱。原因::highlight和::selection是两套独立的绘制层叠加时后绘制的覆盖先绘制的。解决给::selection设一个半透明背景让自定义高亮透出来或者在用户开始手动选择时临时清除自定义高亮选择结束后恢复。4.5 移动端长按选中拖尾现象移动端长按文字时选中手柄拖动过程中自定义高亮区域不跟随更新出现拖尾。原因移动端Selection变化事件触发频率低且Range更新滞后。解决监听selectionchange事件在回调里用requestAnimationFrame延迟一帧再更新高亮避开浏览器自身的选中渲染周期。如果仍然拖尾就在拖动期间隐藏自定义高亮松手后再显示。5. 进阶技巧把高亮做成可复用的独立模块5.1 用 WeakMap 管理高亮状态当页面上有多个独立区域需要高亮时全局的CSS.highlights会互相覆盖。我一般用一个WeakMap把容器和它的高亮命名空间绑起来每个容器用独立的 highlight 名称比如search-hit-article、search-hit-sidebar。这样互不干扰容器销毁时 WeakMap 自动回收。const highlightRegistry new WeakMap(); function getHighlightName(container, type) { if (!highlightRegistry.has(container)) { highlightRegistry.set(container, hl-${Math.random().toString(36).slice(2, 8)}); } return ${highlightRegistry.get(container)}-${type}; } // 使用 const name getHighlightName(article, hit); CSS.highlights.set(name, new Highlight(...ranges));逻辑说明每个容器分配一个唯一前缀所有高亮名称都带这个前缀避免冲突。参数说明type用来区分同一容器内的不同高亮类型比如hit和active。注意CSS.highlights是全局注册表名称冲突时后注册的覆盖先注册的所以前缀必须唯一。5.2 验证高亮是否生效的三个检查点写完高亮逻辑后别急着提测。先做三个检查第一在控制台执行CSS.highlights.get(你的名称)看返回的 Highlight 对象里 Range 数量对不对第二用range.getBoundingClientRect()确认每个 Range 的坐标在可视区域内或附近如果返回全零说明 Range 没有正确关联到文档第三切换主题和缩放窗口确认高亮区域跟随文本重排没有残影。这三个检查点能拦住八成以上的低级问题。5.3 一个我常犯的错误早期做高亮时我总想一次把所有命中都渲染出来觉得“用户可能想看到全部”。结果在长文档里一万多个 Range 直接把页面拖到卡死。后来改成只高亮可视区域加前后各一屏的缓冲滚动时动态增删性能立刻稳了。高亮是给用户看的不是给测试用例看的屏幕上同时出现几十个高亮已经足够剩下的等滚到了再画。这个习惯帮我省了很多后悔药。希望帮到你。本文还有配套的精品资源点击获取 前端高亮方案实战：从CSS Custom Highlight API到DOM包裹的性能调优与避坑
简介Super Highlight 是一款面向浏览器用户的文本高亮插件可视为 Multi-highlight 的升级版本主要解决长文档、文献与网页信息中关键词难以快速定位的问题适合学术研究、资料整理及日常阅读场景使用。资源包共 13 个文件约 131KB以 6 个 js 脚本为核心承载高亮算法与交互逻辑另含 1 个 html 弹窗界面、1 个 json 配置文件、1 个 css 样式表及 4 个 png 图标资源结构紧凑、便于直接加载调试。插件在原有基础上优化了文本输入布局并引入关键词分类固定颜色与分类独立开关用户可按人名、日期、概念等类别设定专属颜色并单独控制各类高亮显示从而提升信息识别与处理效率。目前已有 393 人学习下载适合希望研究浏览器扩展实现方式或需要高效标注文本的读者参考借鉴。1. 从“Super highlight.zip”说起一个高亮方案到底在解决什么如果你在代码托管平台搜过“Super highlight.zip”大概率会看到一堆同名压缩包解压后是几个 CSS、JS 和一份 README。它不是一个官方库更像是一类“高亮增强方案”的统称——把代码块、搜索结果、日志行、表格选中项这些需要被视觉拎出来的内容做得比浏览器默认的mark更可控。真正让人头疼的不是“怎么变黄”而是高亮之后长代码块里高亮错位、暗色主题下对比度崩掉、动态渲染的内容高亮丢失、移动端选中高亮拖尾。这些才是搜索“Super highlight.zip”的人真正想解决的问题。这篇笔记面向需要在前端或文档站里落地高亮能力的工程师从选型、最小实现、参数调优到排错把这条路走通。2. 高亮方案选型为什么不是直接写 background-color2.1 三种主流实现路径的边界在动手之前先把“高亮”这件事拆开。它至少有三个层次静态文本标记、动态范围标记、语义化高亮。静态文本标记就是给一段文字套mark或span classhl改背景色和文字色动态范围标记用Range和SelectionAPI处理用户选中、搜索命中、编辑器内联高亮语义化高亮则要区分“命中关键词”“当前激活项”“上下文预览”等不同状态每种状态有独立的视觉权重。常见做法有三条路。第一条是纯 CSS 类名方案适合服务端渲染好的静态内容成本最低但遇到动态插入的节点就失效。第二条是CSS Custom Highlight API浏览器原生支持把任意Range注册成高亮不污染 DOM适合搜索命中和编辑器场景但兼容性需要确认。第三条是包裹 DOM 节点用span把目标文本包起来再加类名兼容性最好代价是频繁操作 DOM长文档下性能会抖。我一般会先问一句高亮的内容会不会变如果不会变CSS 类名足够如果会随输入、滚动、搜索变化优先考虑 Custom Highlight API如果必须兼容老浏览器再退回 DOM 包裹但要加防抖和范围合并。2.2 最小可运行的高亮实现下面这段代码用CSS Custom Highlight API做一个搜索命中高亮的最小闭环。它不修改 DOM只把匹配到的文本范围注册成高亮。// 检查浏览器是否支持 Custom Highlight API if (!CSS.highlights) { console.warn(当前环境不支持 CSS Custom Highlight API需降级到 DOM 包裹方案); } // 在指定容器内搜索关键词并注册高亮 function highlightKeyword(container, keyword) { // 先清空旧高亮避免叠加 CSS.highlights.clear(); const walker document.createTreeWalker( container, NodeFilter.SHOW_TEXT, null ); const ranges []; let node; while ((node walker.nextNode())) { const text node.textContent; const lowerText text.toLowerCase(); const lowerKeyword keyword.toLowerCase(); let index lowerText.indexOf(lowerKeyword); while (index ! -1) { const range new Range(); range.setStart(node, index); range.setEnd(node, index keyword.length); ranges.push(range); index lowerText.indexOf(lowerKeyword, index keyword.length); } } if (ranges.length 0) { // 注册一个名为 search-hit 的高亮 const highlight new Highlight(...ranges); CSS.highlights.set(search-hit, highlight); } return ranges.length; } // 调用示例 const article document.querySelector(#article); const count highlightKeyword(article, 高亮); console.log(命中 ${count} 处);逻辑说明TreeWalker遍历容器内所有文本节点逐个查找关键词位置用Range精确圈出每一处命中。CSS.highlights.set把一组 Range 注册成命名高亮浏览器负责绘制不插入任何额外节点。参数说明container是搜索范围根节点建议限定在正文区域避免把导航和页脚也扫进去keyword是搜索词大小写不敏感处理在代码里已经做了CSS.highlights.clear()每次调用前清空防止多次搜索后高亮叠加。配套 CSS 只需要一行::highlight(search-hit) { background-color: #ffe066; color: #1a1a1a; }暗色主题下把background-color换成低饱和的#5c4d1f文字色换成#f5f5f5对比度才够。不要直接用纯黄配纯白那是血泪经验看十分钟眼睛就酸。2.3 降级方案DOM 包裹的边界控制如果目标环境不支持 Custom Highlight API就得退回 DOM 包裹。核心思路是把文本节点拆开在命中位置插入mark节点。这里有两个必须控制的参数单次处理的最大文本长度和最大命中数。超过阈值就分片处理否则长文档会卡死主线程。function wrapHighlight(container, keyword, maxHits 500) { const walker document.createTreeWalker(container, NodeFilter.SHOW_TEXT, null); const textNodes []; let node; while ((node walker.nextNode())) { if (node.textContent.toLowerCase().includes(keyword.toLowerCase())) { textNodes.push(node); } } let hitCount 0; for (const textNode of textNodes) { if (hitCount maxHits) break; const text textNode.textContent; const lowerText text.toLowerCase(); const lowerKeyword keyword.toLowerCase(); const fragment document.createDocumentFragment(); let lastIndex 0; let index lowerText.indexOf(lowerKeyword); while (index ! -1 hitCount maxHits) { // 命中前的普通文本 fragment.appendChild(document.createTextNode(text.slice(lastIndex, index))); // 命中部分用 mark 包裹 const mark document.createElement(mark); mark.className hl-hit; mark.textContent text.slice(index, index keyword.length); fragment.appendChild(mark); lastIndex index keyword.length; hitCount; index lowerText.indexOf(lowerKeyword, lastIndex); } // 剩余文本 fragment.appendChild(document.createTextNode(text.slice(lastIndex))); textNode.parentNode.replaceChild(fragment, textNode); } return hitCount; }逻辑说明先把所有包含关键词的文本节点收集起来再逐个替换。DocumentFragment减少真实 DOM 操作次数。参数说明maxHits默认 500超过就停止防止一次搜索把整页拆成几万个节点实际项目里可以配合requestIdleCallback分片执行每帧只处理 50 个节点。注意包裹后的mark节点如果再次被搜索命中会被重复包裹所以每次重新搜索前要先还原原始文本或者用>function setActiveHit(ranges, activeIndex) { if (!ranges.length) return; // 普通命中全部注册 CSS.highlights.set(search-hit, new Highlight(...ranges)); // 当前项单独注册优先级更高 const activeRange ranges[activeIndex]; if (activeRange) { CSS.highlights.set(search-active, new Highlight(activeRange)); // 滚动到当前项 const rect activeRange.getBoundingClientRect(); if (rect.top 0 || rect.bottom window.innerHeight) { activeRange.startContainer.parentElement.scrollIntoView({ block: center, behavior: smooth }); } } }逻辑说明search-hit承载所有命中search-active只承载当前项。CSS 里::highlight(search-active)的优先级天然高于::highlight(search-hit)不需要额外处理。参数说明activeIndex是当前命中在数组里的下标切换时只改这一个值避免全量重绘。注意getBoundingClientRect对 Range 调用时如果 Range 跨多个行盒返回的是第一个行盒的位置长文本换行时滚动定位可能偏上需要额外判断。3.3 性能边界多少命中量会开始卡Custom Highlight API 的性能远好于 DOM 包裹但也不是无限。实测在 5000 个 Range 以内注册和绘制都在 16ms 内完成超过 1 万个 Range首次注册会掉到 30ms 以上滚动时偶发掉帧。DOM 包裹方案在 2000 个节点左右开始明显卡顿因为每次插入mark都会触发样式重算。所以参数上我一般这样定Custom Highlight API 单次最多注册 8000 个 Range超过就只高亮可视区域内的命中DOM 包裹方案单次最多 500 个超过就提示用户缩小搜索范围。可视区域高亮需要监听滚动动态增删 Range复杂度更高但长文档场景下是唯一可行的路。4. 避坑与排查高亮方案落地时的五个翻车现场4.1 高亮错位Range 偏移了一个字符现象搜索“高亮”时高亮区域从第二个字开始或者多高亮了一个字符。原因通常是Range.setStart的 offset 算错了。TreeWalker返回的文本节点里如果包含 HTML 实体比如amp;textContent的长度和源码长度不一致但Range的 offset 是基于textContent的所以只要统一用textContent计算就不会错。真正容易错的是先对textContent做了trim()或toLowerCase()之后用处理后的字符串下标去设 Range长度变了偏移就错了。解决所有下标计算都在原始textContent上进行大小写比较用toLowerCase()的副本但下标取自原始字符串。4.2 暗色主题下高亮“消失”现象切换暗色主题后高亮区域几乎看不见。原因CSS 里只定义了亮色主题的::highlight样式暗色主题下背景色和文字色对比度不足。解决用prefers-color-scheme或主题类名分别定义两套高亮样式暗色下背景色亮度降低、文字色提亮。不要指望浏览器自动反色。4.3 动态内容高亮丢失现象搜索结果加载后高亮正常但用户滚动加载更多内容后新内容没有高亮。原因高亮只在初始 DOM 上执行了一次新插入的节点没有被TreeWalker扫到。解决用MutationObserver监听容器变化新增节点时增量执行高亮而不是全量重跑。增量时注意合并相邻 Range避免碎片化。4.4 高亮与用户选中冲突现象用户手动选中一段文字时浏览器默认的选中高亮和自定义高亮叠在一起颜色混乱。原因::highlight和::selection是两套独立的绘制层叠加时后绘制的覆盖先绘制的。解决给::selection设一个半透明背景让自定义高亮透出来或者在用户开始手动选择时临时清除自定义高亮选择结束后恢复。4.5 移动端长按选中拖尾现象移动端长按文字时选中手柄拖动过程中自定义高亮区域不跟随更新出现拖尾。原因移动端Selection变化事件触发频率低且Range更新滞后。解决监听selectionchange事件在回调里用requestAnimationFrame延迟一帧再更新高亮避开浏览器自身的选中渲染周期。如果仍然拖尾就在拖动期间隐藏自定义高亮松手后再显示。5. 进阶技巧把高亮做成可复用的独立模块5.1 用 WeakMap 管理高亮状态当页面上有多个独立区域需要高亮时全局的CSS.highlights会互相覆盖。我一般用一个WeakMap把容器和它的高亮命名空间绑起来每个容器用独立的 highlight 名称比如search-hit-article、search-hit-sidebar。这样互不干扰容器销毁时 WeakMap 自动回收。const highlightRegistry new WeakMap(); function getHighlightName(container, type) { if (!highlightRegistry.has(container)) { highlightRegistry.set(container, hl-${Math.random().toString(36).slice(2, 8)}); } return ${highlightRegistry.get(container)}-${type}; } // 使用 const name getHighlightName(article, hit); CSS.highlights.set(name, new Highlight(...ranges));逻辑说明每个容器分配一个唯一前缀所有高亮名称都带这个前缀避免冲突。参数说明type用来区分同一容器内的不同高亮类型比如hit和active。注意CSS.highlights是全局注册表名称冲突时后注册的覆盖先注册的所以前缀必须唯一。5.2 验证高亮是否生效的三个检查点写完高亮逻辑后别急着提测。先做三个检查第一在控制台执行CSS.highlights.get(你的名称)看返回的 Highlight 对象里 Range 数量对不对第二用range.getBoundingClientRect()确认每个 Range 的坐标在可视区域内或附近如果返回全零说明 Range 没有正确关联到文档第三切换主题和缩放窗口确认高亮区域跟随文本重排没有残影。这三个检查点能拦住八成以上的低级问题。5.3 一个我常犯的错误早期做高亮时我总想一次把所有命中都渲染出来觉得“用户可能想看到全部”。结果在长文档里一万多个 Range 直接把页面拖到卡死。后来改成只高亮可视区域加前后各一屏的缓冲滚动时动态增删性能立刻稳了。高亮是给用户看的不是给测试用例看的屏幕上同时出现几十个高亮已经足够剩下的等滚到了再画。这个习惯帮我省了很多后悔药。希望帮到你。本文还有配套的精品资源点击获取