Promise的特殊性在于其回调被设计进微任务队列，确保在当前宏任务结束后立即执行且优先于setTimeout等宏任务；.then()等方法注册的回调均入微任务队列，状态变更后必须将其推入微任务而非立即执行，从而保障时序确定性与错误可预测传播。
Promise 的特殊性，不在于它“多厉害”，而在于它被设计进微任务队列这个精确的调度层——这决定了它的回调总比 setTimeout、setInterval 等宏任务更早执行，且在每次宏任务结束后立即清空。
微任务队列的优先级保障
JavaScript 的事件循环每次只取一个宏任务（如脚本主逻辑、setTimeout 回调）执行；一旦该宏任务结束，引擎会立刻暂停宏任务调度，转而执行当前所有已入队的微任务，直到微任务队列为空才继续下一个宏任务。
Promise 的 .then()、.catch()、.finally() 注册的回调，全部进入微任务队列。这意味着：
- 即使 Promise 立即 resolve，其 then 回调也不会在当前同步代码中执行，而是排队等本轮宏任务结束
- 多个 Promise 链式调用产生的 then，会在同一轮微任务中依次执行，不会被中间插入的 setTimeout 打断
- 它天然支持“异步但紧邻”的语义，比如状态更新后立刻触发视图刷新（React 的 setState 在某些版本中就依赖此机制）
与宏任务的根本区别
宏任务（setTimeout、I/O、UI 渲染等）之间存在明确的时间间隔和调度不确定性；而微任务是“引擎强制打包执行”的批次行为。
例如：
console.log(1); setTimeout(() => console.log(2), 0); Promise.resolve().then(() => console.log(3)); console.log(4);
输出一定是 1 → 4 → 3 → 2，因为 3 是微任务，在同步代码（1 和 4）之后、下一个宏任务（2）之前执行。
状态变化与微任务绑定的不可分性
Promise 的状态一旦从 pending 变为 fulfilled 或 rejected，就必须**把对应的 then/catch 回调推入微任务队列**，而不是立即执行。
这个设计保证了：
- 无论你何时调用 .then()，只要 Promise 已完成，回调都能拿到结果（内部缓存 value/reason）
- 多个 .then() 调用不会竞争或丢失，每个都会被独立加入微任务队列
- 错误能统一冒泡：reject 后未捕获的异常，会等到微任务阶段再抛出，方便全局监听 unhandledrejection
它不是“更快”，而是“更确定”
微任务不是为了提速，而是为了提供可预测的执行时序。Promise 不承诺“零延迟”，但承诺“在本轮同步任务之后、下一轮宏任务之前”。这种确定性，让异步流程编排、错误传播、状态一致性变得可控。
