防抖与节流
Debounce & Throttle
高级通用防抖与节流（Debounce & Throttle）是控制高频事件处理频率的两种方法：防抖等事件停下来再处理，节流让处理按一定间隔进行。它们能减少输入、滚动或拖拽时重复计算和请求，降低卡顿与调用成本。
你可能会说：「我打字或拖动时功能要跟得上，但别每动一下就发一次请求。」
读之前建议先了解（这是一个高级概念）
动手看看搜索框的请求节奏
上排模拟在 0、180、360、900 毫秒发生的四次输入。切换处理方式和等待间隔，看下排哪些时刻会发送请求；改参数会自动重播，也可以点重播。
防抖会在每次输入后重新计时，只有安静了足够久才请求。适合搜索建议：用户还在打字时，先别急着查。
间隔较短，反馈更快，但可能发出更多请求。这里防抖发出 2 次，节流发出 3 次。
要点连续触发的事件，怎么决定何时处理？
- 1
防抖等你暂时停下来
你在搜索框连续输入时，每次输入都重新计时；只有一段时间没有新输入，才用当前内容发起搜索。因为中间的字通常不是你要查的完整词，所以可以省掉这些请求。
- 2
节流让处理隔一段时间运行
你拖动地图时，位置会不断变化。如果预览需要跟着移动，就可以按一定间隔更新，而不是每次鼠标移动都更新。这样过程仍有反馈，计算次数也会减少。
- 3
先定响应时机再定间隔
节流要说清第一次触发是否立即处理、停止后是否补处理最后一次；防抖也要确定等待多久。如果最终状态必须准确，例如拖拽结束后的坐标保存，就在结束事件中单独处理，别只依赖定时调用。
- 4
减少调用不等于结果不会过期
防抖能减少搜索请求，但较早发出的请求仍可能比新请求晚返回。因为返回顺序不保证和输入顺序一致，所以展示结果时还要校验查询内容，或取消过期请求。
容易混淆的地方
防抖和节流控制的是事件触发后，处理函数何时运行；它们不等于服务端速率限制。后者约束一段时间内允许多少请求，即使前端做了节流，服务端仍可能限流。它们也不等于背压：当任务产生得比处理得快时，背压还要决定排队、暂停或丢弃哪些任务，而不只是减少触发频率。
什么时候用
适合用
- 后台筛选框支持边输入边查询：用防抖等用户短暂停笔，再请求筛选结果，减少无用查询。
- 画布编辑器拖动元素时要持续显示对齐提示：用节流控制提示计算频率，保留过程反馈。
- 窗口尺寸变化时需要重新计算图表布局：结束后再更新可考虑防抖，变化中也要反馈可考虑节流。
不适合用
- 点击“付款”只发生一次，不是高频事件；要防止重复提交，用按钮禁用状态和服务端幂等处理。
- 后台持续收到大量待处理消息时，单靠节流入口不能解决积压；考虑消息队列容量与背压策略。
- 搜索结果重复请求相同条件且允许复用时，优先考虑缓存；防抖只能减少连续输入期间的调用。
练一练选一个答案，看看解释
你做一个图片裁剪工具：用户拖动裁剪框时，希望预览能持续跟随，但不想每次移动都重新生成预览；松手后必须显示最终位置。怎么处理？
让 AI 帮你做复制给 AI Agent 直接用
请给搜索框输入事件加防抖：用户停止输入一小段时间后再请求，输入为空时清空结果；组件卸载时清理定时器，并避免旧请求晚返回后覆盖新结果。保留输入文字的即时显示，把等待时间做成可调整参数。