很多人以为，JavaScript 定时器不过是“延迟几毫秒”的小问题，但事实远非如此。这个看似微小的偏差，在真实业务场景中可能引发连锁反应：倒计时失真导致秒杀失败、轮询错乱造成连接误判、动画音画不同步、多任务时序断裂引发数据错误。这并非小毛病，而是单线程调度机制在复杂场景下的必然暴露。
接下来，我们从几个常见业务场景入手，看看这个问题的真实危害有多大。
倒计时类业务：时间感知失真
电商秒杀、答题限时、视频弹幕倒计时——用户对“还剩3秒”有明确预期。如果使用 setInterval 每秒更新一次，主线程一旦卡顿200ms，就会跳过一帧渲染；连续卡顿几次，“3秒”可能直接变成“1秒”结束——用户点击时却提示“已截止”。更严重的是，前端自行累加毫秒做倒计时，页面切到后台再切回时，Chrome 的节流机制会将定时器间隔拉长到1秒以上，本地计时瞬间“快进”数秒，与服务器真实剩余时间完全脱节。
轮询与心跳：连接状态误判
实时协作（如在线文档）、IM 消息同步、设备状态上报，这些场景高度依赖定时轮询或心跳保活。假设设定每5秒发一次心跳，但 CPU 占用高或标签页失焦，实际间隔可能变成1.2秒或8秒——前者导致请求洪峰压垮后端，后者让服务端误判客户端离线，直接踢出连接。更隐蔽的是“任务堆积”：每次轮询耗时40ms，而间隔设为50ms，长此以往，多个请求挤在单帧内集中发出，既浪费资源，又掩盖了真实的网络延迟。
动画与音视频同步：感官体验崩塌
Web Audio API 的节拍器、Canvas 动画帧、字幕时间轴，如果依赖 setTimeout 或低频 setInterval，那点微小偏差会逐帧累积。比如每16ms触发一帧（60fps），但主线程阻塞导致某次回调延后8ms，下一次又延后，很快出现卡顿或跳帧。音视频播放器若用 JS 控制播放进度条同步，偏差一旦超过100ms，用户就会明显感到“音画不同步”。
多任务协同逻辑：时序依赖断裂
当多个定时任务需要严格按顺序执行时（例如：先采集数据 → 再压缩 → 最后上报），如果每个任务都用独立的 setTimeout，彼此缺乏协调，竞态几乎是必然结果：采集还没完成，上报任务已启动，传了个空数据；或者压缩任务被阻塞，上报超时重试，导致重复提交。没有统一的时间锚点，各任务只认自己的“局部时间”，整个系统便失去可预测性。
