JS 鼠标滚轮事件频繁触发导致卡顿怎么优化？

一、为什么鼠标滚轮事件会高频触发并引发卡顿？

在日常开发中，现代高采样率鼠标或触控板在轻微滑动时，可以在 1 秒内派发 60 次甚至 120 次以上的 wheel 事件。如果页面仅仅是浏览器原生滚动，现代浏览器会由独立的合成器线程（Compositor Thread）直接处理位移，通常非常平滑。

然而，一旦我们在 JavaScript 中通过 window.addEventListener('wheel', handler) 注册了监听函数，浏览器的运行机制就会发生关键变化：

• 合成器线程被迫等待主线程：浏览器无法预知你的 JS 监听函数内部是否会调用 event.preventDefault() 阻止默认滚动。因此，每次滚轮硬件信号到达后，合成器线程必须先挂起滚动行为，等待主线程执行完 JS 回调并确认未被阻止，页面才会真正发生位移。
• 事件密集入队导致主线程过载：如果 JS 回调中包含耗时计算、DOM 查询或接口请求，处理单个事件的时间一旦超过 8~16 毫秒，待处理的事件就会在主线程的消息队列中堆积，造成严重的掉帧与操作迟滞（Jank）。
• 强制同步布局（Reflow / Layout Thrashing）：许多滚轮业务需要根据当前滚动位置计算视差或元素高亮，如果在回调中一边读取 element.offsetTop、scrollTop，一边修改元素的 style.top，会迫使浏览器在单帧内反复重新计算几何布局，渲染管线不堪重负。

二、核心第一步：开启 passive: true 释放合成器线程

在滚轮事件的性能优化中，最直接且改动成本最低的做法是在注册监听器时明确传递 { passive: true }。

该参数告诉浏览器：本监听函数绝对不会调用 event.preventDefault() 阻止默认滚动行为。浏览器接收到该承诺后，便无需让合成器线程停顿等待主线程的确认，用户手指滚动的瞬间页面即可立刻平滑滑走，JS 计算则在后台异步完成。

// 优化前：可能阻塞原生平滑滚动
window.addEventListener('wheel', handleScroll);

// 优化后：显式声明为被动监听，释放滚动流水线
window.addEventListener('wheel', handleScroll, { passive: true });

三、视觉更新调度：使用 requestAnimationFrame 对齐刷新率

开启 passive: true 解决了原生滚动的流畅度问题，但如果我们需要在滚轮触发时执行自定义动画（例如视差滚动、图片缩放、3D 场景镜头移动），JS 依然需要在主线程中操作 DOM。此时，直接在 wheel 回调中修改 DOM 会导致单帧内重复重绘多次，白白浪费 CPU。

屏幕的物理刷新频率通常是 60Hz（约 16.6ms 每帧）或 120Hz（约 8.3ms 每帧）。无论滚轮在两帧之间触发了 1 次还是 5 次，显示器在这一帧的时间窗口内只能呈现一次画面。因此，最佳做法是：滚轮事件只负责累加记录位置数据，真正的渲染操作交由 requestAnimationFrame 在下一帧渲染前统一执行一次。

// 基于 requestAnimationFrame 建立状态锁的完整实现
let ticking = false;
let scrollDelta = 0;
const targetElement = document.getElementById('parallax-card');

function updateVisual() {
  // 仅在浏览器渲染管线准备刷新时执行真实样式更新
  targetElement.style.transform = `translate3d(0, ${scrollDelta}px, 0)`;
  // 执行完毕后释放标志位，允许下一轮渲染调度
  ticking = false;
}

window.addEventListener('wheel', (event) => {
  // 1. 累积滚动增量或记录当前状态（极轻量计算）
  scrollDelta += event.deltaY * 0.5;

  // 2. 利用 ticking 标志位锁定，避免在单帧内重复调用 requestAnimationFrame
  if (!ticking) {
    window.requestAnimationFrame(updateVisual);
    ticking = true;
  }
}, { passive: true });

这种“状态标志位锁（Ticking Lock）”机制确保了无论鼠标滚轮回报率有多高，页面每秒最多只执行与显示器刷新率完全匹配的渲染次数，既消除了无效的重绘，又避免了肉眼可见的卡顿与撕裂感。

四、降频方案辨析：节流（Throttle）与防抖（Debounce）怎么选？

除了 requestAnimationFrame 之外，社区在处理频繁事件时经常提到防抖（Debounce）与节流（Throttle）。许多新手常将两者混淆，甚至错误地将防抖用于视差滚动，导致页面在滑动过程中毫无响应，松手停下后画面突然突变跳跃。

我们需要根据业务目标的本质属性来决定使用何种降频策略：

以下是使用时间戳实现的简易精准节流函数示例：

// 适用于非视觉渲染类逻辑的节流函数
function throttle(fn, delay = 100) {
  let lastTime = 0;
  return function (...args) {
    const now = Date.now();
    if (now - lastTime >= delay) {
      lastTime = now;
      fn.apply(this, args);
    }
  };
}

// 监听滚动计算当前进度百分比（100ms 触发一次足够准确且省算力）
const handleProgress = throttle(() => {
  const scrollTop = window.scrollY || document.documentElement.scrollTop;
  const docHeight = document.documentElement.scrollHeight - window.innerHeight;
  const percent = Math.min(100, Math.round((scrollTop / docHeight) * 100));
  console.log('当前阅读进度:', percent + '%');
}, 100);

window.addEventListener('scroll', handleProgress, { passive: true });

五、DOM 渲染优化：杜绝强制同步重排与图层合成

有时开发者即使使用了 requestAnimationFrame，页面依然存在掉帧现象。经过性能排查，往往会发现问题出在 updateVisual 内部的 DOM 操作上。

1. 消除强制同步布局（Layout Thrashing）

当 JavaScript 在修改了 DOM 样式之后，立刻尝试读取诸如 element.offsetHeight、element.offsetTop、element.getBoundingClientRect() 等几何属性时，浏览器为了返回准确的数值，必须强行中断当前的 JS 执行流程，立即触发一次重排（Reflow）。

如果在滚轮连续触发时不断发生“修改样式 -> 读取尺寸 -> 修改样式 -> 读取尺寸”，浏览器就会陷入所谓的“布局抖动”。优化原则是读写分离：在滚动循环之前提前读取并缓存静态尺寸，在滚动循环内只做纯粹的数值计算与样式赋值。

2. 优先使用 GPU 合成层属性

在实现元素位移时，避免使用会触发布局重排的属性（如 top、left、margin-top）。取而代之的是使用 transform: translate3d(x, y, 0) 与 opacity。这类属性可以直接交由 GPU 进行图层变换，完全跳过重排与重绘阶段。

对需要频繁滚动的关键动画节点，可在 CSS 中提前声明：

.smooth-layer {
  /* 提示浏览器提前将其提升为独立图层，避免与其他静态元素共用纹理 */
  will-change: transform;
  transform: translate3d(0, 0, 0);
}

六、现代替代方案：使用更轻量的原生 API

在传统前端开发中，许多原本被动监听 wheel 或 scroll 的功能，在现代浏览器中已经有了专门的原生 API，这些 API 在底层通常直接运行在排版引擎内部，完全不占用主线程资源：

• 元素曝光与懒加载：放弃在 wheel 中反复调用 getBoundingClientRect()，改用 IntersectionObserver。浏览器会在元素进入可视窗口时异步通知，效率极高。
• 平滑滚动导航：放弃通过 JS 手写基于 setInterval 的滚轮动画算法，直接在 CSS 中设置 html { scroll-behavior: smooth; }，或者在 JS 中调用 window.scrollTo({ top: 500, behavior: 'smooth' })。
• 滚动驱动动画（Scroll-driven Animations）：现代 CSS 已经开始原生支持 animation-timeline: scroll()，完全可以在不写一行 JavaScript 的情况下，由浏览器合成器线程实现视差滚动与滚动进度条。

七、验证与排查：使用 Chrome DevTools 确认优化成效

代码改造完成后，必须通过客观的工具数据来验证卡顿是否真正被消除。建议使用 Chrome 开发者工具进行以下三项核验：

1. 打开 Performance（性能）面板： 点击录制按钮，用鼠标快速在页面上连续滚动 3~5 秒后停止录制。查看火焰图中的 Main（主线程） 轨道。优化良好的页面在滚动期间，不应出现大面积的红色三角形警告（Long Tasks，执行时间超过 50ms 的长任务），单次任务时间应保持在 5ms 以内。
2. 检查 Frames（帧率）轨道： 观察绿色帧条是否稳定紧贴 60fps（或 120fps）。如果出现黄色或红色掉帧标记（Dropped Frame），点击该帧可以直接定位到导致卡顿的具体 JS 函数调用栈或强制同步布局警告。
3. 启用 Rendering（渲染调试面板）： 在控制台抽屉（More tools）中调出 Rendering，勾选 Scrolling Performance Issues（滚动性能问题）。如果页面上存在未添加 passive: true 的慢速滚动监听器，Chrome 会在对应 DOM 上直接打上半透明的黄色遮罩标记并提示；勾选 Frame Rate Meter（FPS 计数器），则可以在滚动时实时观察瞬时帧率变化。

八、常见疑问与边界场景解答

1. 如果我确实需要通过滚轮阻止默认滚动（例如自定义画板缩放），该怎么办？

当业务需求明确要求拦截页面默认滚动（例如地图拖拽、设计软件的画布 Canvas 鼠标滚轮缩放画布比例）时，不能传递 { passive: true }，因为调用 event.preventDefault() 会被控制台报错且失效。

在这种不得不阻止默认行为的场景下，保持流畅的关键是：在 wheel 回调中仅做两件事：第一步调用 event.preventDefault() 拦截原生滚动，第二步更新目标缩放比变量；严禁在回调内同步遍历画布图形或计算复杂路径。将图形重绘操作同样交给 requestAnimationFrame 去跑，这样即使合成器线程被阻止，主线程的响应时间也被压缩在 0.5 毫秒以内，用户依然感觉不到输入卡顿。

2. 在超长数据列表页面上，仅仅优化滚轮事件有用吗？

如果页面 DOM 节点多达数万个，仅仅对 wheel 事件进行降频和加 passive 仍然可能遇到页面卡顿。这是因为滚轮引起的视口位移会导致浏览器不得不对庞大的 DOM 树进行重绘。此时的优化重心需要前移为虚拟列表（Virtual List），仅渲染屏幕可视区域内的数十个 DOM 节点，让轻量的滚轮逻辑与极简的 DOM 结构协同发挥出最佳性能。