节流是固定频率执行，防抖是停止触发后执行一次；节流适用于需持续响应的场景如滚动监听，防抖适用于只关心最终状态的场景如搜索联想。
节流（throttle）的本质是“固定频率执行”
节流不是阻止函数调用，而是让函数按最大允许频次执行，比如每 200ms 最多执行一次。它适合那些需要持续响应、但又不能太频繁的场景，比如监听页面滚动位置、鼠标拖拽、Canvas 绘图更新。
关键点在于：即使触发非常密集，节流函数内部也会用时间戳或定时器做“节拍控制”，保证执行节奏稳定。
常见错误是把 setTimeout 简单包裹就当节流——那其实是防抖；真正的节流必须区分「立即执行」和「延迟执行」两种模式，且要处理最后一次触发是否遗漏的问题。
典型实现依赖两个状态变量：lastTime（记录上次执行时间）和 timer（用于延迟兜底）。示例如下：
立即学习“Java免费学习笔记（深入）”；
function throttle(fn, delay) {
let lastTime = 0;
let timer = null;
return function(...args) {
const now = Date.now();
if (now - lastTime > delay) {
fn.apply(this, args);
lastTime = now;
} else if (!timer) {
timer = setTimeout(() => {
fn.apply(this, args);
lastTime = Date.now();
timer = null;
}, delay - (now - lastTime));
}
};
}防抖（debounce）的核心是“等停再执行”
防抖只在事件停止触发后才执行一次，中间所有调用都被丢弃。它适用于搜索框输入联想、窗口大小调整后重排布局、表单校验提交前的最终确认等场景——这些操作不追求实时反馈，只关心“用户真正停下来那一刻”的状态。
飞书语音消息发送器。基于 Edge TTS，一键将文字转为语音发送到飞书。 使用场景： - 发送语音通知/提醒到飞书 - 文字转语音自动播报 触发词：飞书语音、语音发送、tts、文字转语音
容易踩的坑包括：误用防抖处理滚动监听，导致页面滚动中完全没响应；或者没清理上一个 setTimeout，造成多次定时器叠加执行。
防抖实现更轻量，通常只需一个 timer 变量 + clearTimeout 即可，但要注意是否需要支持「立即执行首次调用」（leading edge）：
function debounce(fn, delay, immediate = false) {
let timer = null;
return function(...args) {
if (timer) clearTimeout(timer);
if (immediate && !timer) {
fn.apply(this, args);
}
timer = setTimeout(() => {
if (!immediate) fn.apply(this, args);
timer = null;
}, delay);
};
}节流与防抖选型的关键判断依据
不是看“哪个更高级”，而是看业务对「响应连续性」和「最终一致性」的要求权重。
- 需要平滑反馈（如 canvas 跟随鼠标画线、滚动时实时计算吸顶状态）→ 选节流
- 只关心结果（如搜索关键词发请求、resize 后重新计算栅格列数）→ 选防抖
- 用户行为本身有自然间隔（如按钮点击）→ 通常不需要二者，用简单开关或 loading 状态更合适
- 高频事件源不可控（如
mousemove在低性能设备上每秒触发上百次）→ 节流能压降 CPU 占用，防抖可能因始终没“停”而永不执行
现代开发中容易被忽略的细节
原生事件监听器现在支持 { passive: true } 和 { capture: false }，但节流/防抖函数本身不改变事件监听配置。如果用了节流却没设 passive: true，在移动端仍可能触发强制同步布局，导致卡顿。
另外，requestAnimationFrame 是一种特殊的节流形式——它把执行时机交给浏览器渲染帧，比基于时间戳的节流更精准、更节能，但只适用于视觉更新类操作，不能替代通用节流逻辑。
最后提醒：不要在 React 函数组件里每次渲染都新建节流/防抖函数（即不包裹在 useCallback 中），否则会破坏 useEffect 依赖数组稳定性，也可能导致子组件重复绑定事件。
