HTML scroll和resize事件节流方法

未对scroll和resize事件做节流或防抖处理时，页面出现卡顿、掉帧、CPU 飙升几乎是必然结果——这并非简单调整配置就能解决，而是由浏览器底层渲染机制决定的。先列出几个核心结论，后续展开说明具体做法。

那么，scroll事件究竟应该使用传统节流函数，还是采用requestAnimationFrame呢？

scroll事件：节流 vs requestAnimationFrame

传统throttle确实能控制执行频率，但存在一个隐藏问题：可能丢失帧。举例来说，throttle(handleScroll, 100)强制每 100ms 最多执行一次，但如果处理逻辑本身耗时超过 16ms，它仍会挤占浏览器原本的渲染帧。相比之下，requestAnimationFrame天然与浏览器刷新节奏对齐——代码会在下一帧开始前执行，且浏览器切换到后台标签页时自动暂停，节省资源。

实践中，最稳妥的写法是利用一个标志位配合requestAnimationFrame，避免重复注册帧回调：

let ticking = false;function handleScroll() {  if (!ticking) {    requestAnimationFrame(() => {      // 实际滚动逻辑，比如更新视差、计算 sticky 状态      updatePosition();      ticking = false;    });    ticking = true;  }}window.addEventListener('scroll', handleScroll);

resize事件：为什么防抖才是正解

用户调整窗口大小是一个连续拖拽的动作，绝大多数中间过程实际上毫无意义——真正需要响应的，是用户松手后的最终尺寸。防抖（debounce）正是为此而生：在最后一次触发后延迟执行，例如debounce(handleResize, 250)，等用户停止拖拽 250ms 后再重新计算布局。

如果使用节流，反而可能漏掉最终尺寸，特别是在快速拉伸又缩回的场景下。还有一个容易被忽略的点：移动端软键盘弹出收起也会触发resize，防抖能天然过滤这类瞬态变化。

passive: true 能解决scroll卡顿吗

能缓解，但并非万能药。它的作用是告诉浏览器：「我不打算调用preventDefault()，你可以先滚动再说」。这解决了浏览器等待 JS 回调结束才能滚动的阻塞问题，但并不减少回调本身的执行次数。

• 加上{ passive: true }后，preventDefault()不再生效，滚动手感会更顺滑，但处理函数仍会被高频调用
• 因此，它必须与requestAnimationFrame或节流配合使用，否则 CPU 依然吃紧
• 注意旧版 iOS Safari 对passive支持不完整，需要进行特性检测或降级处理

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

IntersectionObserver：替代scroll + getBoundingClientRect

如果目标是判断某个元素是否进入或离开视口，直接使用IntersectionObserver即可，手写计算是典型的性能陷阱。手动调用getBoundingClientRect()并在scroll事件中频繁执行，会强制触发同步布局（Layout Thrashing）——这堪称性能杀手。

IntersectionObserver是浏览器原生的异步 API，零主线程开销，还支持threshold、rootMargin等精细控制。当然，它不能监听window尺寸变化，因此resize场景仍需防抖或ResizeObserver。

const io = new IntersectionObserver(entries => {  entries.forEach(entry => {    if (entry.isIntersecting) {      lazyLoadImage(entry.target);    }  });}, { threshold: 0.1 });io.observe(document.querySelector('.lazy-img'));

真正容易被忽略的点：节流或防抖函数本身如果闭包持有大量 DOM 引用，或者定时器未清理，会在内存中持续驻留；IntersectionObserver和ResizeObserver实例也必须显式调用unobserve()或disconnect()，否则观察者不会被垃圾回收。这些细节，才是高性能事件处理的关键所在。