定时器不是同步机制，而是延时投递宏任务的调度工具；它不感知数据就绪、请求完成或DOM渲染，仅按设定延迟将回调推入任务队列，无法替代Promise等真正的异步协调方案。
JavaScript 定时器本身不参与“数据同步”，它只是调度工具；所谓“用定时器处理异步数据同步”，本质上是一种常见但高风险的误用模式——试图靠时间等待来“凑齐”数据，而非真正理解异步依赖关系。这种做法容易掩盖真实问题，引发逻辑错乱、状态不一致甚至界面假死。
定时器不是同步机制，而是延时投递
setTimeout 和 setInterval 只负责在指定延迟后，把回调函数推入宏任务队列。它不感知数据是否就绪、请求是否完成、DOM 是否渲染完毕。即使写成 setTimeout(() => console.log(data), 100)，也绝不等于“等 data 加载完再执行”。如果 data 还没返回，打印的仍是 undefined 或旧值。
- 定时器触发时机受主线程阻塞影响：前面有长循环或大计算，100ms 定时器可能实际延迟 500ms 才执行
- 多个定时器之间无协调：setInterval 不会自动跳过重叠执行，若回调耗时 > 间隔，会堆积或被丢弃（浏览器会合并重复的 pending 回调）
- 无法响应数据就绪事件：fetch 成功、Promise resolve、MutationObserver 触发等，定时器一概不知
典型风险场景：轮询式“伪同步”
为规避 Promise 或 await 的学习成本，开发者常写如下代码：
let data = null;
fetch('/api/user').then(res => res.json()).then(d => data = d);
// 错误：用定时器“等”data 赋值
const check = setInterval(() => {
if (data) {
render(data);
clearInterval(check);
}
}, 50);
问题在于：
立即学习“Java免费学习笔记（深入）”；
- fetch 是异步，赋值发生在微任务阶段；而 setInterval 回调是宏任务，必然晚于赋值 —— 看似能拿到 data，实则依赖执行顺序巧合
- 网络波动或服务端延迟导致 data 晚于 50ms 才赋值，render 就永远不执行
- 若 fetch 失败，data 始终为 null，定时器无限轮询，CPU 占用升高
- 无法取消：用户跳转页面后，定时器仍在后台运行，造成内存泄漏
真正可靠的替代方案
应放弃“等时间”，转向“等条件”：
- 用 Promise 链或 async/await 显式串联：fetch → .then() → render，天然保证顺序与错误传播
- 封装带超时的数据获取：Promise.race([fetch(...), timeout(3000)])，避免无限等待
- 状态驱动渲染：用 loading/pending 状态控制 UI，数据就绪后 setState 或 reactive 更新，触发自动重绘
- 监听真实就绪信号：如用 AbortController 中断过期请求；监听 DOMContentLoaded 或 useMutationObserver 监测特定节点出现
如果必须用定时器，务必加防护
极少数场景（如兼容老环境、轮询第三方 SDK 就绪状态），需严格约束：
- 设置明确终止条件：最大重试次数、总超时时间、成功标志检测
- 每次执行前清理上一次残留：clearTimeout / clearInterval + 置空 timerId
- 避免在定时器回调中做耗时操作：防止阻塞后续任务，必要时用 requestIdleCallback 或 setTimeout(fn, 0) 切出
- 不用于替代 Promise.all 或 race：多个异步源的协调，必须用原生异步语义，而非时间对齐
