javascript定时器是节奏控制器而非高性能调度答案，需与promise、事件循环协同形成可预测异步流；其核心在于用定时器控制触发时机，再用promise封装执行逻辑。
JavaScript 定时器本身不是高性能调度的“答案”，而是节奏控制器——关键在于它如何与 Promise、事件循环阶段及业务逻辑协同，形成可预测、可取消、可组合的异步流。
用定时器控制执行时机，而非封装异步逻辑
setTimeout 和 setInterval 属于事件循环的 timers 阶段，它们只负责“在某个时间点把回调放进任务队列”，不保证精确执行，也不处理成功或失败。真正需要的是：用定时器决定“何时触发”，再用 Promise 封装“触发后做什么”。
- 防抖：每次新操作重置 setTimeout，最后用 Promise 包装最终执行结果，调用方始终得到一个可 await 的值
- 退避重试：失败后按 100ms → 200ms → 400ms 指数增长延迟，每次 setTimeout 触发一个新的 Promise 执行，错误统一冒泡
- 延迟初始化：setTimeout(() => init(), 0) 不如 Promise.resolve().then(init)，但若需强制跨帧（比如等 DOM 渲染完成），可用 requestIdleCallback 或 setTimeout(..., 1)
避免定时器成为性能瓶颈的三个实操要点
高频或未清理的定时器会持续占用事件循环资源，尤其在低功耗设备上影响明显。优化不是“少用”，而是“用得对”。
- 动画类任务优先用 requestAnimationFrame，它与浏览器渲染帧同步，比 setInterval(16) 更稳定且节能
- 轮询接口时不用固定间隔 setInterval，改用“成功后 delay 再发起下一次”的链式 Promise 调度，避免服务未就绪时空跑
- 所有定时器必须有明确的清理出口：clearTimeout/clearInterval 配合组件卸载、请求取消、状态变更等信号，防止内存泄漏和重复执行
构建可组合的异步调度能力
单个 setTimeout 或 setInterval 很难应对复杂场景。真正实用的做法是把定时器作为底层支撑，向上封装成语义清晰、可嵌套的能力单元。
- createTimeout(promise, ms)：返回 race 超时逻辑的新 Promise，不侵入原逻辑
- createThrottle(fn, delay)：内部维护 lastRun 时间戳 + setTimeout 控制节流，每次调用都返回 Promise，保持调用契约一致
- createRetry(fn, { max: 3, backoff: 'exponential' })：每次失败后用 setTimeout 延迟重试，Promise 状态由 fn 决定，失败时 reject 原始错误
- 这些函数可自由组合：createTimeout(createRetry(fetch), 5000) 表达“最多重试 3 次，总超时 5 秒”
周期任务的安全落地模式
需要反复执行的任务，别依赖 setInterval 的“自动重复”，而应采用带退出条件的主动循环结构。
- 用 async 函数 + while 循环替代 setInterval，每次迭代开头 await new Promise(r => setTimeout(r, interval))，天然支持外部中断（如抛出 AbortError）
- 每次执行前检查前置条件（如网络连通性、token 有效性），不满足则跳过并记录，避免无效轮询
- 状态更新必须幂等：例如用 Redis 的 SET key value EX 60 NX 更新心跳，或数据库 UPSERT 记录最后执行时间，防止重复副作用
- I/O 操作一律设 timeout，耗时操作移交 worker 或消息队列，定时器只做轻量派发
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
