定时器不冲突但执行受主线程阻塞影响：同步任务优先执行，setTimeout回调仅承诺“至少延迟指定时间”，实际执行需等待主线程空闲，最小延迟通常≥4ms。
定时器（setTimeout、setInterval）本身不“冲突”，但它的执行时机常被误认为与同步代码“抢顺序”——实际是 JavaScript 单线程执行机制下自然形成的时序现象：同步任务永远先跑完，定时器回调才可能被执行。
定时器不是“准时钟”，而是“最短等待承诺”
即使写 setTimeout(fn, 0)，回调也不会立刻执行。它只是告诉浏览器：“等主线程空闲后，至少过 0 毫秒再考虑执行我”。如果此时有大量同步计算（比如长循环、复杂渲染），主线程被占满，定时器回调就得排队等到所有同步任务清空后才轮到它。
- 延时参数是“最早可执行时间”，不是“精确触发时间”
- 浏览器最小延迟通常不低于 4ms（尤其在非活跃标签页中可能升至 1000ms）
- 多个
setTimeout的回调按注册顺序进入任务队列，但执行仍受主线程空闲程度影响
同步任务阻塞会直接推迟定时器回调
下面这段代码能清晰体现“阻塞效应”：
console.log('start');
setTimeout(() => console.log('timer'), 0);
for (let i = 0; i < 1e8; i++) {} // 耗时同步计算
console.log('end');
输出一定是：start → end → timer。因为 for 循环是同步任务，它卡住主线程，导致定时器回调无法插入执行栈，哪怕设的是 0 毫秒。
立即学习“Java免费学习笔记（深入）”；
- 任何耗时的同步逻辑（如大数据遍历、正则匹配、JSON.parse 大字符串）都会拖慢定时器响应
- 这不是 bug，是单线程模型的必然表现——JS 不会为定时器“插队”
宏任务队列中的位置决定执行时机
定时器属于宏任务（macrotask），和 setInterval、I/O 回调、UI 渲染同级。它的回调被推入宏任务队列，必须等当前同步任务 + 当前轮次所有微任务（如 Promise.then）执行完后，才从队列头部取出执行。
- 一个
setTimeout注册后，需经历：注册 → 到期 → 入宏任务队列 → 等待本轮微任务清空 → 执行 - 若同一轮中还有
Promise.resolve().then(...)，它一定比定时器回调先运行 - 连续多次
setTimeout可能因主线程繁忙而“堆叠”，造成回调集中爆发
避免误判：别用 setTimeout 模拟精确节拍
想实现每 100ms 执行一次逻辑？仅靠 setInterval 或链式 setTimeout 无法保证精度。一旦某次回调执行超时（比如处理数据花了 120ms），下次就会滞后，形成“越掉越远”的雪球效应。
- 对节奏敏感的场景（动画、音频同步、游戏帧逻辑），应使用
requestAnimationFrame或performance.now()动态校准时间差 - 需要严格周期性调度时，可记录上一次执行时间，在回调开头判断是否已到预期时刻，跳过或合并延迟执行
- 高频定时器建议配合
clearTimeout/clearInterval主动管理，防止内存泄漏或重复注册
