滚动文字跳动是因为requestAnimationFrame被节流或丢帧，导致帧间隔不稳；应基于时间戳线性插值、避免DOM查询、合理使用will-change、改用IntersectionObserver监听视口状态。
滚动文字跳动是因为 requestAnimationFrame 被节流或丢帧
浏览器对 requestAnimationFrame 的调用并非绝对准时，尤其在页面后台、CPU 压力大、或存在长任务阻塞主线程时，帧率会下降甚至跳帧。滚动文字依赖连续帧更新 transform 或 left/top，一旦帧间隔不稳（比如从 16.7ms 变成 33ms 或更长），肉眼就会感知为“跳动”。这不是 CSS 动画的锅，而是 JS 驱动逻辑没守住帧节奏。
- 避免在
requestAnimationFrame回调里执行 DOM 查询（如getBoundingClientRect()）、重排（offsetTop）、或大量计算 - 把滚动位移计算提前到上一帧完成时就准备好，当前帧只做纯样式应用
- 用
performance.now()替代Date.now()获取更精确的时间戳，避免系统时钟抖动干扰匀速判断
CSS will-change 和 transform 3D 强制 GPU 加速但有代价
给滚动容器加 will-change: transform 或 transform: translateZ(0) 确实能触发合成层，减少重排重绘开销，但滥用会导致内存占用升高、纹理上传延迟，反而加剧首帧卡顿或偶发掉帧。尤其在低端安卓 WebView 或 Safari 中，过度分层可能让合成器忙不过来。
- 仅对真正持续滚动的元素设置
will-change，且在滚动停止 200ms 后用 JS 移除它 - 优先用
transform: translateY()而非top或margin-top，确保走合成管线 - 避免同时对多个相邻元素设
will-change，测试发现 Safari 下 3 个以上易触发渲染异常
用 IntersectionObserver 替代 scroll 事件监听滚动状态
监听 scroll 事件再节流（throttle）仍可能漏掉关键帧，且事件回调本身就有调度延迟；而 IntersectionObserver 是异步、低优先级、原生优化的，配合 requestAnimationFrame 更可靠——它只在元素进入/离开视口时触发，适合控制滚动启停，而非实时位移。
- 用
IntersectionObserver检测文字容器是否在视口内，不在时直接暂停requestAnimationFrame循环 - 不要在
scroll事件里调用requestAnimationFrame，这会叠加两层调度延迟 - 若需响应用户手动拖拽滚动条，改用
scrollend事件（Chrome 114+、Edge 114+ 支持），Fallback 则用setTimeout+scrollY变化检测
滚动速率必须基于时间而非帧数做线性插值
很多人写滚动逻辑时用“每帧移动 2px”，这在 60fps 下是匀速，但一旦掉帧，位移就变大，视觉上就是一顿一顿的。正确做法是记录上一帧时间戳，按实际经过的毫秒数计算应有位移量，再四舍五入到像素（避免 subpixel 渲染模糊）。
立即学习“前端免费学习笔记（深入）”；
let lastTime = 0;
const speed = 40; // px/s
function animate(currentTime) {
if (!lastTime) lastTime = currentTime;
const delta = (currentTime - lastTime) / 1000; // 秒
const moveBy = Math.round(speed * delta);
element.style.transform = `translateX(${-moveBy}px)`;
lastTime = currentTime;
requestAnimationFrame(animate);
}注意：这里 Math.round() 很关键——用 toFixed(0) 或直接取整会引入浮点误差累积；而 round 能保持像素对齐，消除因 subpixel 导致的模糊与跳动感。
真正卡住的地方往往不是“怎么动”，而是“什么时候该动、动多少”没和真实时间对齐；还有就是开发者默认认为 requestAnimationFrame 天然保帧，其实它只承诺“下次重绘前”，不承诺“一定准时”。
