防抖和节流需按场景正确选用：输入类用防抖（停顿后执行），滚动/缩放用节流（固定间隔执行）；节流须双保险确保首尾执行；必须透传this和参数；定时器状态须闭包私有化并及时清理。
防抖和节流本是为降频而生，但用错场景、写错逻辑、忽略上下文，反而会引入卡顿、漏执行、this丢失等新问题。避开常见反模式，关键在理解“触发时机”和“执行意图”。
别把节流当防抖用——尤其在输入类场景
给 input 或 keyup 事件加节流，用户快速打字时会明显丢字符或响应滞后。因为节流是「固定间隔最多执行一次」，而输入需要的是「停顿后再执行」。
- ✅ 正确做法：搜索框、表单校验用防抖（等待用户停顿）
- ❌ 反模式：用节流限制输入回调频率，导致中间状态无法及时反馈（如实时字数统计异常、错误提示延迟）
- ? 提示：节流更适合 scroll/resize 这类无需响应每次变化、只关心趋势的场景
定时器版节流丢掉最后一次执行
纯 setTimeout 实现的节流，在连续触发结束时若未到间隔时间，最后一次调用就被丢弃——比如滚动到底部想触发加载，却因没等到下个周期而失败。
Wjs Uploading Video
下载
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
- ✅ 推荐方案：时间戳 + 定时器双保险（即“增强版节流”），确保首次立即执行，末次也兜底执行
- ❌ 反模式：只靠
setTimeout清除+重设，不记录上次执行时间也不做尾调用判断 - ? 关键逻辑：用
Date.now()判断是否该执行；若已过期但还没触发，用setTimeout补一次
忽略 this 和参数透传
直接返回箭头函数或未绑定上下文的包装函数，会导致原函数内部的 this 指向 window 或 undefined，事件对象 event 也拿不到。
- ✅ 正确写法：用
fn.apply(this, arguments)或fn.call(this, ...arguments) - ❌ 反模式：写成
() => fn()（箭头函数固化了外层 this）、或直接fn()（丢失 event 和 target） - ? 小技巧：现代写法可用
fn.bind(this, ...args)，但注意 bind 会返回新函数，需配合闭包缓存
全局变量污染 & 内存泄漏
把定时器 ID（如 timeout 或 timer）声明在全局或模块顶层，多个组件共用同一变量，相互覆盖导致行为不可控。
- ✅ 正确做法：每个防抖/节流函数都通过闭包私有保存自己的定时器状态
- ❌ 反模式：用
let timeout写在函数外部，或在 Vue/React 组件中未清理就挂载多次监听 - ? 必做收尾：组件卸载或监听移除前，手动
clearTimeout/clearInterval，尤其在 SPA 中
