setTimeout不是真正的任务调度器，它仅将回调加入队列等待执行，无法保证准时性，在动画、倒计时、后台标签页等场景下存在不准、不稳、难控三大缺陷。

setTimeout 不是真正的任务调度器，它只是把回调“塞进队列等轮到”，无法保证执行时机。在现代前端场景中，尤其涉及动画、倒计时、长任务分片或后台标签页行为时，它的不准、不稳、不可控会直接暴露出来。

不准：延迟 ≠ 执行时间

你设 delay=100ms，不代表 100ms 后就运行。它只承诺“至少等待 100ms，然后排队等主线程空闲”。一旦当前栈有长任务、样式计算、垃圾回收或大量微任务，回调就得继续排队。

• 实测中，100ms 的 setTimeout 常延迟到 120–180ms 才触发
• 连续调用多个 setTimeout，误差还会累积，抖动明显
• 浏览器对嵌套 setTimeout 有最小间隔限制（通常 ≥4ms），即使写 0 也做不到真正“立刻”

不稳：环境一变，节奏全乱

标签页切到后台、设备锁屏、系统进入节能模式时，浏览器会主动节流定时器——常见降频至 1s 甚至更慢。这不是 bug，而是规范行为。用户切回页面时，可能发现倒计时跳了 3 秒、动画卡顿半秒、心跳包漏发。

Javascript Sdk

用于 inference.sh 的 JavaScript/TypeScript SDK，可运行 AI 应用、构建代理、集成 150+ 模型。包名：@inferencesh/sdk（npm install），完整 TypeScript 支持。

下载

• Chrome、Firefox、Safari 均遵循此策略，且不提供跨浏览器一致的恢复机制
• 移动端 WebView 表现更不可控，部分安卓系统会进一步压缩后台 JS 执行权
• 无法通过代码主动感知或绕过该节流，只能设计容错逻辑

难控：任务堆积、阻塞、无优先级

setInterval 更典型：它机械地按固定间隔往宏任务队列里扔任务，不管前一个是否执行完。若回调耗时 > 间隔，就会出现任务堆积、重叠执行、CPU 持续高负载。

• 比如 setInterval(fn, 100)，但 fn 平均耗时 150ms → 实际变成“刚结束就立刻再进一个”，完全失去节奏感
• setTimeout 递归模拟 setInterval 虽可避免堆积，但依然逃不开事件循环排队和后台节流
• 它没有任务取消信号、无执行上下文绑定、无失败重试、无并发控制能力

更可靠的替代方案

根据使用场景选对工具，比强行调优 setTimeout 更有效：

• 动画与帧同步：用 requestAnimationFrame。它在渲染前触发，与屏幕刷新率对齐（60fps ≈ 16.7ms），不可见时自动暂停，省电又顺滑
• 长任务分片：用 scheduler.yield()（Chrome 129+）。比 setTimeout(0) 更轻量，无 4ms 强制延迟，让出控制权后立即被调度，响应更快
• 高精度倒计时/时钟：不用定时器驱动计时，改用 performance.now() + requestAnimationFrame 循环校准。以真实流逝时间为基准，动态修正显示，规避累积误差
• 后台保活任务：避免依赖 setTimeout/setInterval。改用 Web Workers 处理独立计时逻辑，或结合 Periodic Background Sync（需 HTTPS + 用户授权）做低频唤醒