测试防抖和节流需用 Jest fake timers 模拟时间，通过 jest.useFakeTimers()、jest.advanceTimersByTime() 或 jest.runAllTimers() 控制执行时机，验证调用次数与参数；异步场景需确保仅最后一次 Promise 生效，并清理 mock 和 timers 防止污染。
测试防抖（debounce）和节流（throttle）函数中的异步触发，核心是**控制时间、捕获回调执行时机、验证调用次数与参数**。由于它们依赖定时器（setTimeout / setInterval），必须绕过真实时间等待，用 Jest 的 jest.useFakeTimers() 或类似机制模拟时间推进。
用 fake timers 模拟时间流转
这是最关键的一步。真实等待 500ms 不仅慢，还让测试不可靠。Jest 提供了完整的时间模拟能力：
- 调用
jest.useFakeTimers()启用虚拟计时器 - 用
jest.runAllTimers()立即执行所有待定定时器（适合 debounce 的“立即清空并触发最后一次”） - 用
jest.advanceTimersByTime(ms)精确推进指定毫秒（适合验证节流间隔、debounce 延迟是否生效） - 测试完记得
jest.useRealTimers()还原，避免影响其他测试
验证防抖函数的“最后一次调用生效”
以一个 300ms 防抖函数为例：
const debouncedFn = debounce(fn, 300);
测试逻辑如下：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 连续调用 3 次
debouncedFn('a'),debouncedFn('b'),debouncedFn('c') - 此时不应触发
fn（定时器被反复清除） - 调用
jest.advanceTimersByTime(300)或jest.runAllTimers() - 断言
fn只被调用 1 次，且参数为最后一次传入的'c'
验证节流函数的“固定间隔执行”
节流需检查两点：单位时间内最多执行几次、是否按间隔触发。例如 200ms 节流：
- 在 0ms、50ms、100ms、150ms、250ms 各调用一次
throttledFn() -
jest.advanceTimersByTime(200)→ 应触发第 1 次（0ms 那次） -
jest.advanceTimersByTime(200)→ 应触发第 2 次（250ms 那次，因 200ms 窗口已刷新） - 断言
fn.mock.calls.length === 2，且两次调用时间戳差 ≈ 200ms（用mock.invocationCallOrder或记录Date.now()辅助）
处理异步回调（如 Promise、fetch）的特殊点
如果防抖/节流包裹的是返回 Promise 的函数（比如搜索请求），测试重点变为：
- 确保只有最后一次调用的 Promise 被真正 resolve/reject（前序调用应被忽略或取消）
- 若内部用了
AbortController实现取消，需 mockfetch并检查 signal 是否被 abort - 若只是简单忽略前序调用，可用
await最后一个调用的 Promise，并断言它返回预期结果；同时用expect(fn).toHaveBeenCalledTimes(1)确保只发一次请求 - 避免在测试中
await所有调用——未被触发的 Promise 不会 resolve，会导致测试超时
不复杂但容易忽略：务必在每个测试用例开头清理 mock 和 timers，比如 fn.mockClear() + jest.clearAllTimers()，否则状态会污染后续测试。
