17370845950

节流是按固定时间间隔执行函数，首次触发立即执行，后续每wait毫秒最多执行一次；核心用时间戳判断差值，确保过程快照而非最终状态。

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

节流就是给函数“装上发车时刻表”：不管用户疯狂滚动、拖拽或点击多少次，throttle 保证它每 wait 毫秒最多执行一次。不是等“安静下来”，而是按固定节奏“匀速输出”。

常见错误现象：
– 滚动时监听位置做懒加载，没加节流 → 每帧都触发计算，页面卡顿掉帧
– 鼠标拖拽更新坐标，直接绑定 mousemove → CPU 占用飙升，响应延迟明显

• 核心判断逻辑是时间戳差值：if (Date.now() - lastTime >= wait) 才执行
• 推荐用时间戳实现（而非定时器标记），避免因事件暂停导致“漏帧”
• 注意：throttle 不会丢弃首次调用 —— 第一次触发立即执行，后续才开始限频

防抖（debounce）和节流最根本的区别在哪？

不是“写法不同”，而是「业务语义完全不同」：防抖要的是“最终状态”，节流要的是“过程快照”。

举个真实例子：
– 搜索框输入用 debounce：用户敲完“react hooks”才发请求，中间删改全不发
– 页面滚动监听用 throttle：哪怕用户猛滚，也要每 100ms 检查一次是否接近底部，不然“加载更多”会严重延迟

• 防抖：连续触发 → 全部忽略，只留最后一次停顿后的执行
• 节流：连续触发 → 每隔 wait ms 执行一次，其余全部节流掉
• 参数名虽都叫 wait，但含义不同：防抖的 wait 是“静默等待期”，节流的 wait 是“最小执行间隔”

手写 throttle 时最容易踩的三个坑

很多网上抄来的实现看似能跑，上线后却出问题。

• 坑1：用 setTimeout + 布尔标记（inThrottle） → 用户快速连续触发，可能因定时器未及时清空导致“执行两次”
• 坑2：不处理 this 和 arguments → 绑定到 DOM 元素时，func 内部的 this 指向丢失
• 坑3：忽略首次立即执行需求 →

  

  有些场景（如拖拽起始点）必须第一次就响应，得加 leading: true 选项，纯时间戳实现需额外判断

推荐最小可用版（带首次执行）：

function throttle(func, wait) {
  let lastTime = 0;
  return function(...args) {
    const now = Date.now();
    if (now - lastTime >= wait) {
      func.apply(this, args);
      lastTime = now;
    }
  };
}

什么时候该选节流而不是防抖？看这三点

别靠感觉，直接对照场景 checklist：

• 需要感知“过程”而非“结果”？→ 是（如滚动位置、鼠标移动轨迹）→ 选 throttle
• 函数执行本身有副作用且不能跳过？→ 是（如发送心跳、更新 canvas 坐标）→ 选 throttle
• 延迟执行会导致体验断裂？→ 是（如拖拽中坐标跳变、游戏射击延迟）→ 必须用 throttle，且建议 wait ≤ 16ms（逼近 60fps）

真正容易被忽略的点：节流不是“万能减速器”，如果 wait 设太大（比如 500ms），用户操作会明显滞后；设太小（比如 10ms），又几乎退化成无防护 —— 实际项目中，100ms 是滚动/拖拽较稳妥的起点，再根据设备性能微调。