真正不卡的高亮是用 transform+opacity 模拟，通过绝对定位 overlay 层避开重排重绘，配合 will-change 动态启停、预创建元素和 requestAnimationFrame 批量更新实现 60fps。
HTML动态高亮卡顿，根本不是“高亮逻辑太复杂”，而是浏览器在每一帧里反复做重排（Layout）和重绘（Paint）——尤其当你用 backgroundColor、color、border 或 outline 等属性触发样式变更时，几乎必然掉帧。
为什么 highlight 会触发重排？
浏览器对高亮的常见实现方式（比如给元素加 class="highlight" 并在 CSS 里写 background-color: #ffeb3b）会直接修改布局相关属性。哪怕只是改个背景色，只要该元素有浮动、inline-block、或影响周围流式布局，就可能引发父容器甚至整行重排。
-
background-color本身不触发重排，但若元素同时设置了padding、border或box-shadow，且这些值在高亮前后不同，就会触发重绘+重排连锁反应 - 用
innerHTML或textContent插入带span.highlight的文本，会强制浏览器重建文本行框（line box），尤其在长段落中代价极高 - 高频切换（如鼠标划过单词逐个高亮）若没节流，
requestAnimationFrame都救不了——因为样式变更本身就在主线程排队等 Layout
用 transform + opacity 模拟高亮效果
真正不卡的高亮，是“看起来像高亮”，但底层只动合成层属性。核心思路：把高亮层抽成独立 DOM 节点，用 transform 定位、opacity 控制显隐，完全避开 Layout 流程。
- 不要直接改目标元素样式，而是用
getBoundingClientRect()获取位置后，动态创建一个<div class="highlight-overlay">，绝对定位覆盖其上<li>overlay 只设 <code>background: #ffeb3b+opacity: 0.8+transform: translateZ(0)（触发 GPU 合成） - 高亮切换时只更新
style.transform（如translate(120px, 45px)）和style.opacity，不碰top/left/width - 批量高亮多个区域？复用同一 overlay 元素，用
requestAnimationFrame批量更新transform，避免每项都触发一次样式计算 - 只在用户开始划词瞬间（如
mousedown或touchstart）给 overlay 加style.will-change = 'transform, opacity' - 高亮结束 100ms 后（用
setTimeout或requestIdleCallback），必须执行el.style.will-change = 'auto'清除 - 绝对不要给整个列表容器或
body加will-change，哪怕它里面全是可高亮文本 - Chrome DevTools → Layers 面板里能看到是否真被提升为独立图层；如果灰色“Composite Layer”没出现，说明
will-change没生效或被忽略 - 避免在
scroll或mousemove中实时调用getClientRects()；改用requestIdleCallback延后读取，或缓存上一次结果并仅在resize或内容变化时刷新 - 高亮匹配词时，别用正则全局替换
innerHTML；改用document.createDocumentFragment()构建新节点，再一次性replaceChild - 移动端 Safari 对
Selection的处理更慢，若检测到navigator.userAgent.includes('iPhone')，直接降级为光标附近 200px 内的粗略 DOM 查找 - 首屏加载后立即高亮？确保所有文本节点已 layout 完成——用
requestAnimationFrame(() => { /* 高亮逻辑 */ })包一层，否则getBoundingClientRect()返回 0
will-change 什么时候该加、什么时候必须删？
will-change: transform, opacity 对高频高亮场景有用，但滥用等于自埋性能地雷——它会让浏览器提前分配纹理内存，长期挂着会导致图层爆炸、内存飙升。
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
立即学习“前端免费学习笔记（深入）”；
文本节点高亮的隐藏陷阱：Range 和 Selection 开销
用 document.getSelection() 或 Range API 做语义级高亮（比如选中一段文字后高亮所有同义词），看似优雅，实则极易卡顿——因为每次 range.getClientRects() 都会触发强制同步布局。
最易被忽略的一点：高亮动画的“起始帧”往往比中间帧更卡。因为首次创建 overlay、计算位置、触发图层提升，全挤在第一帧里。务必在用户交互前（比如 hover 到高亮按钮时）就预创建好空的 overlay 元素，并设好 pointer-events: none 和初始 opacity: 0，等真正需要时只改 transform 和 opacity —— 这才是真·60fps 的起点。
