节流防的是高频事件导致的页面卡顿、重排频繁和CPU飙升；它通过限制回调函数固定间隔最多执行一次来优化性能，支持leading（首次立即执行）和trailing（结束补发）控制。

节流（throttle）到底在防什么？

滚动事件 scroll 在用户拖动或触屏滑动时会高频触发——每秒可能几十次。直接在里面执行 DOM 操作或计算，极易导致页面卡顿、重排频繁、CPU 占用飙升。节流不是“阻止触发”，而是“强制让回调函数按固定间隔最多执行一次”，比如限制为 100ms 内只执行首次或末次调用。

手写一个可靠且带 leading/trailing 控制的 throttle 函数

网上很多简化版节流漏掉关键边界：比如首次是否立即执行（leading）、最后一次滚动停止后是否补发（trailing）。真实场景中两者常需同时支持。以下实现兼顾可读性与健壮性：

function throttle(func, wait, options = {}) {
  let timeout = null;
  let previous = 0;
  const { leading = true, trailing = true } = options;
const later = () => {
previous = leading ? Date.now() : 0;
timeout = null;
if (trailing && timeout === null) {
func();
}
};
const throttled = function(...args) {
const now = Date.now();
if (!previous && !leading) previous = now;
const remaining = wait - (now - previous);
if (remaining <= 0 || remaining > wait) {
  if (timeout) {
    clearTimeout(timeout);
    timeout = null;
  }
  previous = now;
  func(...args);
} else if (!timeout) {
  timeout = setTimeout(later, remaining);
}
};
throttled.cancel = () => {
if (timeout) {
clearTimeout(timeout);
timeout = null;
}
};
return throttled;
}
使用示例：
– 立即执行首次滚动，后续至少等 16ms（≈60fps）再执行：throttle(handleScroll, 16, { leading: true, trailing: false })
– 更保守：首次不执行，滚动停稳后补一次：throttle(handleScroll, 100, { leading: false, trailing: true })

为什么不用 requestAnimationFrame 替代 throttle？
requestAnimationFrame（raf）确实能将执行对齐到浏览器刷新节奏，但它的触发时机不可控：只要页面没被冻结，它每帧都调用，无法限制“最小间隔”。比如快速滚动 2 秒，raf 可能仍会执行 120 次；而 throttle(..., 100) 最多执行 20 次。二者定位不同：
– raf 适合动画渲染类操作（如视差、滚动位置同步）
– throttle 适合逻辑判断类操作（如吸顶导航切换、懒加载临界点检测）
实际项目中常组合使用：用 throttle 控制入口频率，内部再用 raf 做视觉更新。
监听 scroll 时容易忽略的兼容性细节
滚动容器不一定是 window，可能是某个 div 元素，此时必须监听其 scroll 事件，而非全局；另外 iOS Safari 下，scroll 在弹性滚动结束前不会触发，需配合 touchend + setTimeout 补偿（尤其当 trailing: true 时）。还有两个硬坑：
– 使用 passive: true 时，无法在事件中调用 preventDefault()，但节流函数里通常不涉及此操作，可以放心加
– Vue/React 中绑定事件若未手动 removeEventListener 或清理 throttle 返回的函数，会导致内存泄漏