Promise 的 then/catch/finally 回调作为微任务按 FIFO 顺序执行，resolve/reject 同步调用也不打断当前同步流程，链式调用逐级触发微任务，且与 queueMicrotask 等共享微任务队列。
当 Promise 被解析（resolve 或 reject）时，其对应的 then、catch、finally 回调会被作为微任务（microtask）推入微任务队列，并在当前宏任务执行结束后、下一个宏任务开始前，按**先进先出（FIFO）顺序**依次执行。
Promise 状态变更触发微任务入队
Promise 构造函数中传入的执行器函数是同步执行的，但其中调用 resolve 或 reject 并不会立即执行后续的 then 回调。它们只是将回调函数注册为微任务，等待当前同步代码执行完毕后统一处理。
- 即使 resolve 是同步调用的，then 回调也一定在本轮宏任务末尾执行，不会打断当前同步流程
- 多个 Promise 链式调用产生的 then/catch 会按注册顺序排队，而非按 resolve 时刻排序
- 同一个 Promise 上多次调用 then，回调按调用顺序入队；不同 Promise 的 then 则按各自 resolve 时间和注册顺序混合入队
微任务队列与 Promise 链的执行节奏
每个 then/catch/finally 返回的新 Promise，其状态确定时又会生成新的微任务。这意味着 Promise 链不是“一次性展开”，而是逐级触发微任务：
- p.then(a).then(b) 中，a 执行完并返回值（或新 Promise）后，才将 b 推入微任务队列
- 如果 a 返回一个已决议的 Promise，b 仍需等待本轮微任务清空后才执行（即进入下一轮微任务）
- reject 后被 catch 捕获，该 catch 回调也是微任务；若 catch 中返回值，后续 then 依然在之后的微任务中执行
与其他微任务的共存关系
Promise 回调和其他微任务（如 queueMicrotask、MutationObserver 回调）共享同一个微任务队列，按插入顺序执行：
立即学习“Java免费学习笔记（深入）”；
- queueMicrotask(fn) 和 Promise.then(fn) 插入的回调，在同一轮微任务阶段中严格按调用先后排队
- 但 Promise 内部实现可能有轻微优先级差异（如 V8 中 Promise 回调略早于 queueMicrotask），不过规范仅保证同类型内 FIFO，跨类型不保证绝对顺序，应避免依赖
- 实践中建议：若需强顺序，统一用 queueMicrotask 或全部走 Promise 链，不要混用并假设执行次序
常见误区提醒
容易误以为“先 resolve 的 Promise，它的 then 就一定先执行”——其实不然：
- let p1 = Promise.resolve(); let p2 = new Promise(r => setTimeout(r, 0)); p1.then(...) 先入队，p2.then(...) 后入队，所以 p1 的回调一定先执行
- 但如果 p1 是异步 resolve（如封装了 setTimeout），而 p2 是同步 resolve，则 p2.then 先注册、先入队，反而先执行
- 关键不在“谁先完成”，而在“谁的 then 先被调用、谁的 resolve 先触发注册”
