requestAnimationFrame 本身不修复视觉撕裂，但能避免强制重排、错配刷新节奏等导致撕裂的典型错误；关键是在 rAF 回调中仅读轻量属性、只做纯位移写入、配合图层提升与像素对齐。
requestAnimationFrame 本身不直接“修复”视觉撕裂，但它能帮你避开导致撕裂的典型错误路径：在 scroll 事件里同步改样式、触发强制布局、或用 setTimeout 错配刷新节奏。
为什么编辑器滚动会撕裂？不是显示器问题，是 JS 干了不该干的事
HTML 编辑器（比如基于 contenteditable 或自研渲染层的）在长文档中滚动时，常见撕裂表现是：文字块错位、光标跳动、行高忽大忽小、背景色断层。根本原因不是 DOM 太多，而是你在每次 scroll 触发时做了这些事：
- 直接读
getBoundingClientRect()或写el.style.top—— 强制浏览器立刻重排（forced synchronous layout） - 用
setTimeout(() => { updateUI() }, 0)做节流 —— 回调时机不可控，可能跨帧、堆积、跳帧 - 在滚动中持续更新 CSS 变量（如
--scroll-y）并依赖它驱动 transform —— 但没控制更新节奏，导致 GPU 层合成不同步 - 未提升图层，让文本渲染和滚动位移混在同一合成层，CPU 和 GPU 协作打架
用 requestAnimationFrame 实现滚动位置采样 + 延迟 UI 更新
关键不是“每滚一像素就更新一次”，而是“每帧最多更新一次 UI，且只读轻量值”。真实可行的链路是：
- 监听
scroll时加{ passive: true }，确保滚动不被 JS 阻塞 - 只在回调里记下最新
scrollTop或scrollLeft到一个变量（如latestScrollY），不做任何 DOM 操作 - 用
requestAnimationFrame启动一个持续采样循环，在回调里读latestScrollY，再批量更新视图（比如调整虚拟滚动的transform、更新高亮行范围、重设光标位置） - 如果编辑器有“粘性标题”或“浮动工具栏”，别用
position: sticky硬扛，改用transform: translateY()+will-change: transform，并在 rAF 回调里算好偏移值后一次性写入
避免在 rAF 回调里踩 layout thrashing 坑
rAF 不是万能解药——它只是给了你一帧的执行窗口，但如果你在里面反复读写布局属性，照样卡顿撕裂。必须守住两条线：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 读取只用
el.scrollTop、el.scrollHeight、el.clientTop这类不触发重排的属性；绝对不用offsetHeight、getComputedStyle(el).height、el.getBoundingClientRect() - 写入只做“纯位移”：用
transform: translateY(${y}px)替代top/margin-top；所有动画值提前算好，rAF 回调里只做一次el.style.transform = ... - 如果必须响应滚动做高亮（比如当前段落加背景），不要在 rAF 里实时计算 DOM 范围，改用预存的
lineHeights数组 + 二分查找快速定位可视区间，再批量 patch
配合图层与整数对齐才能真正消除撕裂感
即使用了 rAF，若没做合成层优化，GPU 仍可能把文本块当普通图层处理，导致位移模糊或边缘锯齿。必须补上这几点：
- 给编辑器容器加
transform: translateZ(0)或临时加will-change: transform（滚动开始前加，100ms 后移除） - 所有
transform值用Math.round(y)对齐像素，避免 subpixel 渲染（例如translateY(123.456px)→translateY(123px)） - 禁用任何针对滚动容器的
transition，它和 rAF 冲突，且无法中断 - 如果编辑器支持代码行号或折叠图标，确保它们和文本内容在同一个合成层，否则会出现相对位移错位
真正难的不是调用 requestAnimationFrame，而是在那一帧里只做确定量的事、只读确定属性、只写确定样式，并且让 GPU 知道“这部分我来管”。撕裂从来不是帧率低，而是帧与帧之间状态不一致。
