js项目中mock全局定时器的核心是替换原生方法以控制时间流。jest推荐用jest.usefaketimers()劫持定时器，配合runalltimers()或advancetimersbytime()执行/快进，测试后调用userealtimers()恢复；手动mock需同步替换set/cleartimeout并维护id映射；react中需验证useeffect清理逻辑，注意浏览器环境参数、第三方库兼容及requestanimationframe需单独mock。
在 JS 项目中，用 Mock 模拟全局定时器（setTimeout、setInterval、clearTimeout、clearInterval）主要是为了隔离副作用、控制时间流、避免测试阻塞或竞态问题。核心思路是：**替换原生定时器为可控的模拟实现，让时间“快进”或“立即执行”，而非真实等待。**
使用 Jest 自带的 timer mock（最常用）
Jest 提供了开箱即用的定时器模拟能力，无需额外库，适合大多数单元测试场景。
- 在测试文件顶部或
beforeEach中调用jest.useFakeTimers()，Jest 会劫持全局定时器方法 - 触发待测逻辑（如组件挂载、函数调用），此时
setTimeout不会真实延迟，而是把回调存入队列 - 用
jest.runAllTimers()立即执行所有已注册的定时器回调 - 或用
jest.advanceTimersByTime(ms)快进指定毫秒数，只执行该时间段内到期的回调 - 测试结束后建议调用
jest.useRealTimers()恢复原生行为（尤其在非 isolated 测试环境）
手动 mock 全局定时器（需精细控制时）
当 Jest 默认行为不够灵活（比如要 mock 返回值、记录调用栈、或在非 Jest 环境中），可直接覆盖全局对象：
Wjs Uploading Video
下载
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
- 在测试前保存原始方法：
const originalSetTimeout = global.setTimeout - 用
jest.fn()或自定义函数替换：global.setTimeout = jest.fn((cb, ms) => { /* 存入队列或立即调用 */ }) - 注意同时 mock
clearTimeout并维护 ID 映射关系，否则清理逻辑可能失效 - 推荐封装一个轻量 timer controller 类，统一管理 pending 定时器、执行/跳过/取消逻辑，提升复用性
在 React 组件中处理定时器副作用（如 useEffect）
组件内常见的 useEffect(() => { const id = setInterval(...); return () => clearInterval(id); }, []) 需确保 mock 后仍能正确清理：
- mock 后，
setInterval返回的 “id” 可以是任意唯一值（如数字索引），clearInterval只需识别并标记该 id 已取消 - 测试中调用
act(() => { render(<mycomponent></mycomponent>); })，再jest.runAllTimers()，验证回调是否按预期触发 - 断言清理逻辑：mock
clearInterval，检查它是否被调用，且参数匹配setInterval的返回值
注意边界与常见坑
Mock 定时器不是万能的，几个关键细节容易出错：
-
jest.useFakeTimers()默认只 mock Node.js 环境下的定时器；浏览器环境需加{ timers: ['setTimeout', 'setInterval'] }参数 - 异步代码中混用
await waitFor(...)和 fake timers 时，确保waitFor内部不依赖真实时间（它本身会配合 fake timers 自动重试） - 第三方库（如 Lodash
debounce）内部也用定时器，若未被 mock，可能导致测试不一致 —— 建议统一启用 fake timers 并覆盖全部目标方法 - 真实 DOM 动画帧（
requestAnimationFrame）不属于定时器 mock 范围，需单独处理（如 mockrequestAnimationFrame为setTimeout）
