防抖节流问题根源在于状态管理错、边界判断漏、版本混用乱；需修复定时器闭包、立即执行逻辑、this/参数绑定、兜底触发、重复绑定及调试验证等关键点。
防抖和节流写出来看似几行代码，但线上常出现“该执行没执行”“不该执行却执行了多次”“首次/末次丢失”“页面切后台后暴发式触发”等问题。根源不在语法，而在状态管理错、边界判断漏、版本混用乱。下面直击高频 Bug 类型和对应解法。
一、防抖函数执行次数异常：不是1次，而是0次或多次
典型表现：输入框连续打字，预期停顿后只查一次，结果没查、查了两次、或每次输入都查。
-
原因1：定时器未用闭包正确保存——把
timer声明在函数内部（非闭包变量），每次调用都新建一个，清不掉旧的；正确做法是用let timer = null在外层闭包中持久化 -
原因2：立即执行版逻辑错位——
if (immediate && !timeoutId)判断后直接执行，但没阻止后续定时器里再执行；必须确保!immediate分支只在定时器到期时触发 -
原因3：this 或参数丢失——没用
fn.apply(this, arguments)或解构...args，导致目标函数执行上下文错误、参数为空
二、节流函数频率失控：本该每200ms一次，结果卡住不执行或密集连发
典型表现：滚动监听下，快速滚动时完全没响应；或切到其他标签页再切回，瞬间触发十几次。
Wjs Uploading Video
下载
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
-
时间戳版失效：只比对
Date.now() - lastTime >= delay，但若用户滚动极快（如 50ms 一次），可能永远跨不过间隔，导致全程不执行；应补上「兜底触发」逻辑，比如配合定时器保证 trailing 执行 -
定时器版堆积：用
setTimeout实现时，没加if (!timer)判断就直接设新定时器，旧定时器仍在后台运行，切回页面时集中触发 -
lastTime 初始化错误：设为
0没问题，但若误设为Date.now()，首次触发就因时间差为 0 被跳过，造成“首屏无响应”
三、框架中重复绑定导致多套状态并存
典型表现：React 组件内每次 render 都重新调用 debounce(fn, 300)，结果绑了5个防抖实例，每个都有独立 timer，一输就触发5次。
-
React 场景：防抖/节流函数必须定义在
useCallback中，并将fn和delay作为依赖；或直接在组件外层定义（如 utils 文件），避免每次渲染重建 -
Vue 场景：不要在
methods里直接写debounce(...)，应提前在created或setup中缓存实例，或使用v-on:input="debouncedHandler"绑定已缓存函数 - 通用原则：工具函数返回的是新函数，不是单例；谁创建谁负责生命周期，别让事件监听器“偷偷多生几个孩子”
四、调试与验证的关键动作
光看代码难定位，得让状态“看得见”。
-
加简易日志：在定时器设置、清除、执行处打印
console.log('debounce: set', Date.now())，观察是否成对出现 -
暴露取消方法：给防抖函数加
.cancel()方法，在组件卸载或切换时主动清理，避免内存泄漏和误触发 - 用 performance.now() 替代 Date.now()：高精度时间戳可更准确判断节流间隔，尤其在性能敏感场景
-
模拟极端操作测试：用脚本连续触发 50 次事件（如
for (let i=0; i），验证最终执行次数是否符合预期
