别再只写 setTimeout 了：JS 防抖函数的进阶优化实战

搜索框里每敲一个字都发一次请求？调整窗口大小时界面疯狂重绘直到卡死？这些性能杀手大多源于事件触发频率过高。虽然“防抖”是前端面试和开发的常客，但网上随手抄的一段 setTimeout 代码，在实际项目中往往埋着不少雷。今天咱们不谈理论定义，直接聊聊怎么把防抖函数写得既能抗高并发，又兼顾用户体验。

很多初级的防抖实现长这样：创建一个变量存定时器 ID，触发事件就清除旧定时器再设新的。这种写法看似没问题，但在复杂场景下有两个致命硬伤：一是无法中途取消，二是丢失了执行上下文。 想象一下，用户在输入框快速输入时突然关闭了弹窗或销毁了组件，后台那个定时器却没停，依然尝试去调用接口。这不仅浪费服务器资源，还可能因为组件已卸载而导致报错。

要解决这个隐患，核心在于给防抖函数增加一个“自毁开关”。我们需要在返回的包装函数上挂载一个 cancel 属性。当业务逻辑判断不需要继续等待时，直接调用这个方法手动清除定时器。这样一来，即便页面跳转或组件卸载，内存中的计时任务也能被彻底打断，避免潜在的内存泄漏风险。

紧接着是一个关乎体验的关键点：何时执行。有些业务场景，比如点击提交按钮，我们希望第一次点击立即响应，之后的快速连点才需要过滤；而搜索场景则希望等用户停手再发送请求。通过引入 immediate 布尔值参数，我们可以灵活控制这一行为。当开启该选项时，利用一个标志位记录状态：若当前无定时器，立即执行回调并设置延时器防止下次立即执行；若已有定时器，则照常重置时间。这种“首尾皆可控”的逻辑，能适配更多元化的交互需求。

别忘了最容易被忽视的 this 指向问题。原生函数里的 this 是动态绑定的，如果直接在防抖内部执行 fn.call(this)，很容易导致引用错误。稳妥的做法是在外层返回的函数中，捕获当前的 arguments 和 this 环境，在定时器到期时再通过 fn.apply(context, args) 统一转发。这样无论你在哪里使用这个封装好的防抖，都能确保它始终在预期的对象环境下运行。

如果是处理异步请求，还可以进一步思考是否返回一个 Promise 对象。传统的防抖只是延迟执行，并不关心结果。但如果将其改造为支持异步Await的样式，就能更好地配合现有的异步流程控制，避免多个未决请求互相覆盖数据的问题。

工具的生命力在于适配。一个好的防抖函数不应只是几行代码的堆砌，而是对清理机制、执行时机、上下文绑定的综合考量。在实际编码前，花几分钟理清业务需求，选择带 cancel 能力的增强版方案，远比后期上线后再来修复卡顿事故要明智得多。记住，代码的健壮性，往往藏在这些不起眼的细节里。