定时器回调属于宏任务，优先级低于微任务但高于渲染和i/o等宏任务；即使延迟为0，也需等待当前同步代码及所有微任务执行完毕后才可能执行，且受浏览器节流或node.js事件循环阶段影响。
JavaScript 中定时器回调函数（如 setTimeout 和 setInterval）不属于高优先级异步任务，它们的执行时机由事件循环调度，实际优先级低于微任务（如 Promise.then、MutationObserver），但高于渲染、I/O 等宏任务中的其他类型（如用户交互、网络请求回调）。
定时器属于宏任务，排队等待当前任务栈清空
当调用 setTimeout(fn, 0) 时，浏览器或 Node.js 并不会立刻执行 fn，而是将其注册为一个宏任务，放入「宏任务队列」（Task Queue）。它必须等到当前执行栈为空、所有微任务执行完毕后，才可能被事件循环取出执行。
- 即使延迟设为 0，也至少要等完当前同步代码 + 所有已入队的微任务
- 如果前一个宏任务耗时很长（比如长循环），定时器回调会被明显推迟
- 多个
setTimeout按注册顺序排队，但不保证严格按时序——只保证“至少延迟指定毫秒后”才进入队列
微任务总在宏任务之间插队执行
这是理解优先级的关键：每次宏任务执行完，引擎会清空整个微任务队列，然后再取下一个宏任务。因此，哪怕 setTimeout 先注册，只要后面有 Promise.resolve().then(...)，后者一定先执行。
- 示例：同步代码 →
Promise.then（微任务）→setTimeout回调（宏任务） - 即便
setTimeout延迟为 0，也无法抢占刚完成的宏任务之后的微任务机会 -
queueMicrotask行为与Promise.then一致，同样优于定时器
浏览器中还受页面可见性与节流策略影响
在标签页非激活状态（如切换到其他 tab 或最小化窗口）时，多数浏览器会对定时器进行节流：setTimeout 最小延迟可能被拉长至 1000ms 甚至更高，以节省资源。这进一步降低了其“准时性”和相对优先级。
- 后台标签页中，
setTimeout(fn, 10)可能延迟数秒才触发 - 使用
requestIdleCallback或Page Visibility API可感知并适应这种降级 - 对时效敏感的任务（如动画帧、实时通信心跳）应避免依赖
setTimeout的精确间隔
Node.js 环境下略有不同但逻辑一致
Node.js 的事件循环阶段更明确：定时器阶段（timers phase）专门处理到期的 setTimeout/setInterval；但该阶段仍排在 poll 阶段之后、check 阶段之前，且每次进入 timers 阶段前，都会先执行完本轮产生的微任务。
- Node.js 中
process.nextTick属于“微任务之上”的特殊队列，比Promise.then还早执行 -
setImmediate属于 check 阶段，通常比同轮次的setTimeout更晚执行（除非延迟为 0 且 timers 阶段无到期任务） - 实际开发中，优先用
Promise处理链式异步，用定时器仅作“延后执行”而非“精确调度”
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
