陈竹之我第一次真正意识到节流（throttle）有多重要，是在一个移动端搜索结果页的滚动加载场景里。页面滚动时 scroll 事件在低端安卓机上每秒钟能触发几十次，我在回调函数里直接发起了接口请求，结果用户只是随手划了两下屏幕，后端已经连续收到七八个请求，列表数据乱跳、页面卡顿，线上问题一串串冒出来。后来排查性能才明白，问题的根源不在于接口响应慢，也不在于渲染逻辑复杂，而在于 js 函数的执行频率完全没有被控制住。
节流做的事情其实特别简单：无论事件触发得多频繁，保证目标函数在固定时间间隔内最多执行一次。它不会让单次操作变快，但能让高频操作变得可控，这是前端性能优化里最基础也最实用的一招。这篇文章我从原理、实现、实战坑位到面试追问，把节流这件事完整拆一遍，适合刚接触前端的初学者，也适合想把这个知识点真正吃透的进阶开发者。
1. 节流到底在解决什么问题
1.1 一个必须上节流的真实场景
先说我最开始提到的滚动加载。移动端页面里 scroll、touchmove、resize 这类事件有一个共同特征：触发频率远远高于你实际需要处理数据的频率。浏览器在滚动过程中，每一帧都会触发多次 scroll 事件，而且这个过程是不受开发者控制的——用户手指轻轻一动，事件流就像开闸放水一样涌进来。
在没有做任何限制的情况下，如果你把网络请求、DOM 操作、复杂计算这些逻辑直接挂在这些事件上，代价可能比你想象的大得多。以滚动加载为例，用户从页面顶部滑到底部，scroll 事件可能触发了上百次，但合理的数据加载次数其实只有几次——每次快到底部时加载下一页就够了。额外发出的那些请求，不仅浪费用户流量，还会给服务器带去无意义的压力，更重要的是会让页面出现竞态问题：多个请求的返回顺序不一致，数据互相覆盖。
类似的场景还有 resize 事件。窗口大小变化时，如果你在回调里做了重排重绘、图表尺寸重算，哪怕只是把窗口从 1920 拉宽到 1921，也可能触发一连串昂贵的计算。这类高频事件才是节流的主战场。它的核心思路是：把“每触发一次就执行一次函数”改成“每个时间段内至多执行一次”，相当于给函数加了一道限流阀门。
1.2 节流为什么有效：从调用频率到代价控制
理解节流，关键是想清楚一件事情：高频事件带来的不一定都是"有用调用"。举个例子，用户拖动窗口调整大小，resize 事件可能会触发 50 次，但用户最终停留的位置只有一个。这 50 次里，前面 49 次的结果都是中间态，只有最后一次会成为用户真正看到的界面。节流做的事情就是主动放弃那些中间态的执行机会，只保留每个时间段内一次有代表性的执行。
我在项目里经常用地铁闸机的例子来解释节流。每秒钟可能有几十个人涌到闸机口，但闸机每两秒只放一个人通行，没被放行的人不会消失，他们只是在排队等待下一个闸机开启的时刻。节流函数也是这个逻辑：事件来了就先看时间窗口是否开放，开放就执行，不开放就跳过或者记住最后一次请求。
这里要注意一个容易被忽略的点：节流减少了函数的执行次数，但并不会减少事件的触发次数。事件该触发多少次还是多少次，只是回调函数不再随事件频率同步执行了。所以从性能上看，收益来自两个层面：一是减少了网络请求和计算量，二是减轻了主线程的负担，让浏览器能把资源留给渲染和交互。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 节流与防抖：先分清边界再写代码
2.1 两个概念的直观对照
很多前端初学者会把防抖（debounce）和节流（throttle）混为一谈，坦白说这两个概念确实长得很像，它们都是限制函数执行频率的手段，但适用场景完全不同。我在面试候选人时，最怕听到的回答是"防抖就是一直触发不执行，停了才执行；节流就是固定时间执行一次"，概念背得没问题，一旦追问到场景判断就露馅了。
先给一个直观的对照表：
| 维度 | 防抖 (debounce) | 节流 (throttle) |
|---|---|---|
| 执行时机 | 停止触发后延迟执行 | 固定时间间隔内最多执行一次 |
| 典型场景 | 搜索框输入联想、窗口 resize 结束后重算 | 滚动加载、拖拽、点击防连击 |
| 执行次数 | 高频触发时可能一次都不执行 | 保证至少按时间间隔执行 |
| 核心追求 | 等用户"停"下来再做事 | 让执行频率匀速可控 |
判断用哪个，其实只需要问一个问题：你关心的是"最后一次操作的结果"，还是"持续操作过程中的稳定输出"？搜索联想关心的是用户最终输入完的那几个字，中间的过程没有意义，所以用防抖，等用户停在某个词上不再输入了，再发起请求。滚动加载关心的是用户滚动过程中需要持续加载数据，不能等滚动停下才加载，否则用户滑到底部要干等很久，这时必须用节流。
2.2 选错方案的典型后果
这两种方案选错了，后果非常直观。我踩过的一个印象深刻的坑是：一个同事把搜索联想做成了节流，每 500ms 发一次请求。用户输入"苹果手机壳"，前几个字还没打完，请求已经发出去了，回传的结果跟后续输入完全不匹配。这就是典型的把防抖场景用节流来做——节流保证的是"每隔一段时间执行一次"，但搜索联想根本不需要周期性执行，它只需要在用户真正停下来的时候执行一次。
反过来，如果把滚动加载做成防抖，用户快速滑动页面时永远等不到"停止触发"的那一刻，防抖函数的定时器一直被刷新，结果就是数据迟迟不加载，页面滚到底了还在转圈圈。这两种错误在真实项目里都不罕见，而且报错方式往往不是直接崩溃，而是"界面行为很怪"，特别难排查。
所以我的建议是：写代码之前先记录一下这个事件是持续性的还是