应将定时器抽象为可注入依赖并配合Jest fake timers测试：定义调度器接口、生产用原生setTimeout、测试用模拟实现；启用fake timers后用advanceTimersByTime或runAllTimers控制时间；暴露start/stop控制点；单次延迟优先用Promise封装便于await断言。
用 setTimeout 或 setInterval 直接写业务逻辑，会让单元测试变得困难——因为真实时间不可控、副作用难隔离。核心思路是：把定时器行为抽象出来，让调用方能控制“何时触发”，而不是依赖真实时钟。
把定时器封装成可注入的依赖
不要在函数内部直接调用 setTimeout，而是通过参数或依赖注入接收一个“调度器”对象：
- 定义统一接口，比如
{ setTimeout: (cb, delay) => number } - 生产环境传入原生
window.setTimeout，测试时传入模拟实现（如立即执行、或手动推进时间） - 例如：
function startPolling(fetchData, scheduler = window) {<br> const poll = () => {<br> fetchData().then(() => {<br> scheduler.setTimeout(poll, 5000);<br> });<br> };<br> poll();<br>}
用 Jest 的 fake timers 精确控制时间流
Jest 内置了时间模拟能力，无需额外库就能冻结、快进、清理定时器：
- 测试前调用
jest.useFakeTimers()替换全局定时器 - 用
jest.advanceTimersByTime(ms)跳过指定毫秒，触发已注册的回调 - 用
jest.runAllTimers()立即执行所有待处理定时器 - 测试后记得
jest.useRealTimers()恢复，避免影响其他测试
避免隐式定时器，显式暴露控制点
如果代码中存在“自动启动”的定时器（如组件挂载时开始轮询），测试时很难干预。应提供明确的启停方法：
立即学习“Java免费学习笔记（深入）”；
- 返回一个包含
start()和stop()的控制器对象 - 内部保存定时器 ID，
stop()调用clearTimeout/clearInterval - 测试中可先
start()，再advanceTimersByTime()，最后stop()验证清理行为
用 Promise 封装单次延迟，便于 await 和断言
对于简单延迟逻辑（如防抖、延后执行），优先用返回 Promise 的工具函数代替裸 setTimeout：
- 例如：
const delay = (ms) => new Promise(res => setTimeout(res, ms)) - 测试中可
await delay(100)，配合 fake timers 实现零等待验证 - 比直接操作回调更符合现代异步风格，也更容易链式断言后续状态
