Promise的回调属于微任务，因其在当前宏任务结束后立即执行、不等待下一轮事件循环，由ECMAScript规范明确要求加入微任务队列，确保高响应性与及时的状态处理。
Promise 为什么属于微任务
Promise 的 .then()、.catch()、.finally() 回调被设计为在当前宏任务结束后**立即执行**，不等待下一轮事件循环。这是由 JavaScript 规范（ECMAScript）明确规定的：当 Promise 状态变为 fulfilled 或 rejected 时，其关联的处理函数会被加入**微任务队列（microtask queue）**。
关键点在于调度时机：
- 它不抢占当前同步代码，但也不排队等下一轮——而是在调用栈清空后、浏览器可能渲染前，**强制清空整个微任务队列**
- 嵌套的 Promise.then 会持续追加新微任务，全部在本轮内串行执行，不会中途切到宏任务
- 这使得 Promise 非常适合做“紧接同步逻辑之后的异步响应”，比如状态更新后立刻触发视图刷新准备
setTimeout 为什么属于宏任务
setTimeout 的回调被放入**宏任务队列（macrotask queue）**，哪怕延时设为 0，也必须等到当前宏任务彻底结束、所有微任务执行完毕、甚至 UI 渲染（在浏览器中）发生之后，才可能被取出执行。
它的定位是“延迟调度”，不是“尽快响应”：
- 用于 I/O 轮询、定时重试、解耦长任务、避免阻塞主线程等场景
- 和 setInterval、I/O 回调、整体 script 标签一样，共享同一层级的调度优先级
- 即使多个 setTimeout(0) 连续注册，它们也按插入顺序排队，且每个都要等前一个宏任务走完才能轮到
事件循环如何协调两者
JavaScript 引擎运行时遵循严格节奏：
- 执行一个宏任务（例如：整个 <script> 块、一个 setTimeout 回调、一次用户点击事件处理器）</script>
- 过程中遇到 Promise.then → 加入微任务队列；遇到 setTimeout → 加入宏任务队列
- 该宏任务的同步代码执行完毕，调用栈为空 → 立即执行所有已排队的微任务（包括过程中新推入的）
- 微任务队列彻底清空 → 浏览器可选渲染（仅限浏览器环境）→ 从宏任务队列取下一个任务开始新一轮
这个机制保证了微任务的高响应性，也防止宏任务无限挤压 UI 更新机会。
一个典型验证示例
看这段代码：
console.log('1');setTimeout(() => console.log('2'), 0);
Promise.resolve().then(() => console.log('3'));
console.log('4');
输出一定是：1 → 4 → 3 → 2
- 1 和 4 是同步代码，在第一个宏任务中直接打印
- 3 是微任务，在同步结束后立刻执行
- 2 是宏任务，要等第一个宏任务 + 所有微任务都完成，再开启下一轮事件循环才执行
这个顺序不是偶然，是事件循环规则的必然结果。
