最有效测试方式是高频模拟触发+控制台日志+performance面板观察；防抖应只在最后一次触发后delay执行，节流需稳定间隔wait执行，时间戳比对与fps/内存分析是验证关键。
直接用高频模拟触发 + 控制台日志 + 性能面板观察，是最有效、最贴近真实压力的测试方式。关键不是“能不能跑”，而是看它是否按预期逻辑吞并或稀释调用，以及主线程是否被拖累。
用定时器暴力触发，验证执行次数和时机
防抖和节流的核心是“控频”，所以测试第一要务是制造远超正常用户操作的触发密度（比如每 5ms 触发一次），再检查实际执行是否符合设定逻辑。
- 防抖测试：设 delay=300ms，用
setInterval(fn, 5)持续触发 2 秒，应只看到 1 次执行（最后一次触发后 300ms）；若开启immediate=true，则第 1 次会立刻执行，之后直到停止触发再等 300ms 才执行第 2 次 - 节流测试：设 wait=200ms，同样每 5ms 触发，应看到执行时间点大致为 0ms、200ms、400ms、600ms…（误差在几毫秒内），总执行次数 ≈ 实际运行时长 ÷ 200ms，而不是几百次
- 注意：别用
for循环直接调用函数，那只是同步压栈，测不出异步调度效果；必须用setTimeout或setInterval模拟事件循环中的真实触发节奏
加时间戳打印，确认防抖重置和节流间隔是否生效
光看 console.log 的条数不够，要确认每次执行的确切时间，才能判断逻辑是否被正确干预。
Wjs Uploading Video
下载
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
- 在防抖包装函数内部，
console.log('debounce exec at', Date.now())放在fn.apply()前；同时在触发源头也打点：console.log('trigger at', Date.now()) - 对比两组时间戳：若连续多次 trigger 在 300ms 内，但只有最后一个 trigger 后约 300ms 出现 exec，说明防抖重置成功
- 节流同理：exec 时间戳之间的差值应稳定落在设定 wait 值附近（如 198–202ms），而非忽大忽小或堆在一起
打开 Chrome DevTools 的 Performance 面板实测
这是判断“是否真优化”的黄金标准。极端高频下，未优化代码会让主线程持续忙碌，帧率骤降；而合格的防抖/节流应让主线程有明显空闲间隙。
- 录制前勾选 Screenshots 和 Event Log，录制 3~5 秒高频触发过程
- 查看 Flame Chart：理想状态是 JS 执行块（绿色）短而分散，中间穿插大片空白（idle）；若出现长条状连续 JS 调用，说明函数没被控住，或者内部逻辑太重
- 关注 FPS 曲线：优化后应稳定在 50~60fps；若掉到 10~20fps，要么节流间隔设得太小，要么防抖函数里做了同步 DOM 查询等重操作
- 留意内存曲线：如果每次触发都新建闭包或对象且未释放，内存会阶梯式上涨——这是防抖节流没写好（比如 timer 没清、闭包引用未断）的典型信号
模拟真实事件源，避免测试失真
单纯用 setInterval 测试虽简单，但和真实 scroll/mousemove 仍有差异：原生事件有捕获/冒泡阶段、可能被 passive 干预、触发时机受渲染帧影响。所以进阶测试建议：
- 对滚动测试：用
element.scrollTop += 1配合requestAnimationFrame每帧推进，比 setInterval 更贴近浏览器滚动行为 - 对输入测试：用
inputEl.value = 'xxx'; inputEl.dispatchEvent(new Event('input'))主动派发，确保触发绑定在 input 事件上的防抖函数 - 禁用 passive：若测试 scroll，记得加
{ passive: false }，否则 touchstart 等事件会被浏览器静默忽略，导致“看似没触发”
