防抖节流失效主因是“何时重置”“何时放行”“状态如何保持”理解偏差；常见问题包括定时器未清除、this/参数丢失、冷却状态未恢复、时间戳与定时器混用、重复绑定及参数传递错误。
防抖和节流写错，最常表现为函数该执行时不执行、不该执行时却执行多次，或执行时机完全偏离预期。问题根源不在语法，而在对“何时重置”“何时放行”“状态如何保持”这三个关键点的理解偏差和实现疏漏。下面直击高频排错点，结合典型场景还原真实踩坑过程。
防抖失效：延迟没清掉，或 this/参数丢了
常见错误是定时器变量未用闭包保存，或在 setTimeout 回调中直接调用 fn() 而非 fn.apply(context, args)。结果就是：多次输入后只执行第一次的值，或者 this 指向 window 导致 DOM 操作失败。
- 检查 timer 是否声明在闭包内（如 debounce 函数内部），避免多个实例共用一个 timer 变量
- 必须在包装函数内保存 this 和 arguments，并在 setTimeout 回调中用 apply 或 call 显式绑定
- 立即执行版防抖容易漏掉“首次执行后禁用定时器”的逻辑，导致第二次触发仍立即执行
节流卡死：冷却状态没恢复，或时间戳/定时器混用混乱
节流有两种主流实现：时间戳版（靠时间差判断）和定时器版（靠 valid 标志位）。混用二者会导致逻辑冲突——比如用时间戳判断是否该执行，却又在 setTimeout 里设 valid = true，而 clearTimeout 并未同步处理。
- 时间戳版需始终记录 lastTime，每次触发都比对 Date.now() - lastTime ≥ delay 才执行并更新 lastTime
- 定时器版需确保：触发时若无活跃定时器则启动，执行完回调后才重置标志位；不能在 setTimeout 外部提前设 valid = true
- 滚动场景下若节流函数返回 undefined 或未 return 包装函数，事件监听可能被意外解绑
搜索框与滚动加载：两个案例的典型翻车现场
搜索框用防抖却仍发了多次请求？大概率是 debounce 返回的函数被重复绑定到 input 事件上，每次绑定都新建一个 timer 作用域，旧的 timer 清不掉。滚动加载用节流却触底检测失灵？往往因为 throttle 包装后的函数没有正确传递 event 参数，导致 scrollTop 计算出错，或节流间隔设得太长（如 1000ms），用户快速滚动时根本等不到下一次执行。
- 搜索框务必确保：debounce(fn, 300) 只绑定一次，不要在每次 input 中重新调用 debounce
- 滚动加载推荐时间戳版节流，它响应更及时；避免用定时器版配合 requestIdleCallback 等异步调度，易引发竞态
- 所有防抖/节流函数都应支持 cancel 方法，便于页面卸载或切换时手动清理定时器，防止内存泄漏
调试技巧：三步快速定位问题
不用打断点也能快速验证逻辑是否正常。在防抖/节流函数内部加三处 console.log：触发时打 “start”，clearTimeout 前打 “clear”，setTimeout 回调开头打 “run”。观察控制台输出顺序和时间戳，就能立刻判断是重置失败、延迟未生效，还是执行被跳过。
- 连续触发三次，预期看到 start → clear → start → clear → start → clear → run（防抖）
- 连续触发五次，间隔 200ms，delay=500ms，节流应输出 start → run → start → start → start → run（每 500ms 一次）
- 把 delay 设为 0，看是否变成“每次触发都执行”——这是检验防抖/节流是否真正介入的最快方式
