debounce 和 throttle 到底差在哪？200 次连续输入实测触发次数

一次输入 200 个事件，同一份数据同时喂给 debounce 和 throttle，谁触发几次、差在哪，页面当场报数。

先把结论摆出来。

同一段 200 事件的输入流，debounce 只触发 6 次，throttle 触发 22 次，差了 16 次。

源码在本案例目录可直接下载：https://atomgit.com/deli007/demo_park/tree/main/codearts-debounce-throttle-lab
生成物只有一个 index.html，纯前端、零依赖、不联网，全部计算都在浏览器里完成。

它不是严谨的框架基准测试，只是一台看得见的演示台。

为什么值得看：一个等「停」，一个按「表」

这两个词几乎总是成对出现，含义却相反。

debounce 盯的是停顿：事件一直来，它就一直等，等安静下来才动手。

throttle 盯的是节拍：不管事件多密，它按固定间隔动手，到点就触发。

搜索框联想怕请求过多，该用 debounce。

滚动加载怕漏掉中间状态，该用 throttle。

选反了，要么每敲一个字母就发一次请求，要么滚动时半天不动。

所以我没打算复述书上的定义，而是写了一段固定的输入流，让两个函数真跑一遍，用数字说话。

进入 AI 开发者空间（码道 Web）

打开 https://devcloud.cn-north-4.huaweicloud.com/chat/home ，用自然语言描述你要做的应用，就能开始。

页面不用安装，浏览器里打开就能对话。

这份输入流是怎么造的

页面用固定种子生成 200 个事件，中间夹着 6 段密集连打和 6 段停顿。

首末事件跨度 5773ms，差不多 5.8 秒。

种子写死在代码里，所以每次打开都是同一条输入流，数字可复现。

真正难的从来不是画图，是让「实测」两个字经得起核对。

这条输入流是造出来的，不是真实用户流量。

所以它说明的是两种实现的差异，不是线上压测的吞吐结论。

自检里那句「密集连打 13 段」是按 300ms 滑窗数出来的，比肉眼分的 6 段更细。

怎么做与踩坑

第一版里，throttle 的理论值是用估算公式算的，和实测差了 41%，对不上。

我没有凑数，改成让主实现真跑，再拿一个独立写法重算一遍做对照。

throttle 的参考实现走窗口扫描写法，维护 lastRun 和计时器逐段推演。

页面主实现走定时器队列写法，两套算法思路完全不同。

同一条输入流下，两套实现都给出 22 次，差 0。

踩得最深的一个坑，是 throttle 的 trailing 开关。

关掉 trailing 之后，最后一段连打的收尾事件没人接，直接被丢掉。

页面会弹一条红色错误提示，写明尾段丢了 24 个事件，整条流一共丢弃 185 个。

实测触发次数也从 22 掉到 15。

这条提示不是装饰，它是「配置写错时会发生什么」的现场演示。

本地复现

生成物只有一个 index.html，纯前端、零依赖、不联网。

把文件存到本地，双击就能打开。

想用静态服务也行：python -m http.server 8000，然后访问 http://localhost:8000 。

页面上点「内置自检」，应该看到 14/14 通过。

自己拖一遍参数更直观：debounce 延迟调到 50ms 是 6 次，调到 1000ms 只剩 1 次。

再把 throttle 的 trailing 关掉，触发次数从 22 变成 15，红色提示同时出现。

使用码道体会

这轮下来，最省事的一条是把验收方式写进需求。

我在需求里直接写「完成后打开预览」，模型就自己跑了一遍，省掉一轮来回确认。

第二条是断言要给出参考值。

我要求自检覆盖「跨度落区间、debounce 次数不超过 throttle、immediate 首触发接近 0」，它就把 14 条真的做进了页面。

只写「加个自检」，多半只能换来一句打印。

第三条是把模糊描述翻成可执行的判据。

「平滑」翻成具体缓动，「丢事件」翻成 trailing 关闭后统计到的丢弃数，页面数字才对得上。

直接下载试玩

• 仓库地址：https://atomgit.com/deli007/demo_park
• 本案例目录：https://atomgit.com/deli007/demo_park/tree/main/codearts-debounce-throttle-lab

总结

回到最开始那个问题，debounce 和 throttle 差的不是实现，是「等谁」。

debounce 等事件停下来，所以触发次数由停顿决定。

throttle 等时间到点，所以触发次数由跨度决定。

想接着玩，可以把延迟滑到两端看次数怎么变，也可以给输入流加一段超长停顿，看 debounce 的组数怎么动。