节流是按固定时间间隔执行函数，首次触发立即执行，后续每wait毫秒最多执行一次；核心用时间戳判断差值，确保过程快照而非最终状态。
节流（throttle）到底在做什么？
节流就是给函数“装上发车时刻表”：不管用户疯狂滚动、拖拽或点击多少次，throttle 保证它每 wait 毫秒最多执行一次。不是等“安静下来”，而是按固定节奏“匀速输出”。
常见错误现象：
– 滚动时监听位置做懒加载，没加节流 → 每帧都触发计算，页面卡顿掉帧
– 鼠标拖拽更新坐标，直接绑定 mousemove → CPU 占用飙升，响应延迟明显
- 核心判断逻辑是时间戳差值：
if (Date.now() - lastTime >= wait)才执行 - 推荐用时间戳实现（而非定时器标记），避免因事件暂停导致“漏帧”
- 注意：
throttle不会丢弃首次调用 —— 第一次触发立即执行，后续才开始限频
防抖（debounce）和节流最根本的区别在哪？
不是“写法不同”，而是「业务语义完全不同」：防抖要的是“最终状态”，节流要的是“过程快照”。
举个真实例子：
– 搜索框输入用 debounce：用户敲完“react hooks”才发请求，中间删改全不发
– 页面滚动监听用 throttle：哪怕用户猛滚，也要每 100ms 检查一次是否接近底部，不然“加载更多”会严重延迟
立即学习“Java免费学习笔记（深入）”；
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 防抖：连续触发 → 全部忽略，只留最后一次停顿后的执行
- 节流：连续触发 → 每隔
waitms 执行一次，其余全部节流掉 - 参数名虽都叫
wait，但含义不同：防抖的 wait 是“静默等待期”，节流的 wait 是“最小执行间隔”
手写 throttle 时最容易踩的三个坑
很多网上抄来的实现看似能跑，上线后却出问题。
-
坑1：用
setTimeout+ 布尔标记（inThrottle） → 用户快速连续触发，可能因定时器未及时清空导致“执行两次” -
坑2：不处理
this和arguments→ 绑定到 DOM 元素时，func内部的this指向丢失 -
坑3：忽略首次立即执行需求 → 有些场景（如拖拽起始点）必须第一次就响应，得加
leading: true选项，纯时间戳实现需额外判断
推荐最小可用版（带首次执行）：
function throttle(func, wait) {<br> let lastTime = 0;<br> return function(...args) {<br> const now = Date.now();<br> if (now - lastTime >= wait) {<br> func.apply(this, args);<br> lastTime = now;<br> }<br> };<br>}
什么时候该选节流而不是防抖？看这三点
别靠感觉，直接对照场景 checklist：
- 需要感知“过程”而非“结果”？→ 是（如滚动位置、鼠标移动轨迹）→ 选
throttle - 函数执行本身有副作用且不能跳过？→ 是（如发送心跳、更新 canvas 坐标）→ 选
throttle - 延迟执行会导致体验断裂？→ 是（如拖拽中坐标跳变、游戏射击延迟）→ 必须用
throttle，且建议wait ≤ 16ms（逼近 60fps）
真正容易被忽略的点：节流不是“万能减速器”，如果 wait 设太大（比如 500ms），用户操作会明显滞后；设太小（比如 10ms），又几乎退化成无防护 —— 实际项目中，100ms 是滚动/拖拽较稳妥的起点，再根据设备性能微调。
