JS测试中可通过Jest的jest.useFakeTimers()跳过setTimeout延迟，调用runAllTimers()立即执行或advanceTimersByTime()推进时间，结束后用useRealTimers()恢复；非Jest环境可手动mock setTimeout，但应避免修改业务代码。
在 JS 项目测试中，setTimeout 的延迟可以通过 模拟（mock）或替换全局定时器 来跳过，无需真实等待。核心思路是控制时间流逝的“感知”，而不是修改业务代码逻辑。
使用 Jest 内置的 fake timers
Jest 提供了开箱即用的 jest.useFakeTimers()，它会拦截所有 setTimeout、setInterval 等调用，让它们不真正触发，而是被记录下来，供你主动推进时间或立即执行。
- 在测试前调用
jest.useFakeTimers() - 触发含
setTimeout的逻辑（如点击、函数调用） - 用
jest.runAllTimers()立即执行所有待处理的定时器 - 或用
jest.advanceTimersByTime(ms)推进指定毫秒数 - 测试结束后建议调用
jest.useRealTimers()恢复（尤其在afterEach中）
手动 mock setTimeout（适用于非 Jest 环境）
若用其他测试框架（如 Vitest、Mocha），可直接重写全局 setTimeout：
- 保存原始方法：
const originalSetTimeout = global.setTimeout - 替换为同步执行的版本：
global.setTimeout = (fn, ms) => fn() - 记得在测试后还原：
global.setTimeout = originalSetTimeout - Vitest 用户推荐用
vi.useFakeTimers()，API 类似 Jest
注意异步时序与清理
跳过延迟只是加速测试，但不能忽略实际行为是否符合预期：
- 确保你在
runAllTimers()后再做断言，否则回调可能还没执行 - 如果定时器被
clearTimeout取消，需验证清除逻辑是否生效（fake timers 也支持跟踪已清除的 timer） - 避免在多个测试间共享 fake timers 状态，每个测试应独立 setup/teardown
不推荐：修改业务代码加测试钩子
比如给 setTimeout 包一层可配置的 delay，或暴露 timer ID 供测试清理——这会污染生产逻辑，增加维护成本。优先用环境级的 timer 控制，而非侵入业务。
