嵌套与外层.then()共用同一微任务队列，按注册时机和Promise状态决议顺序分批入队，严格FIFO执行；同步resolve的嵌套.then()属本轮清空，异步resolve则延至下轮。
嵌套的 .then() 和外层链式 .then() 都进入同一个微任务队列，但**不是同时入队，而是按“注册时机”和“Promise状态决议顺序”逐级、分批入队**——关键在于：谁先被注册、谁的状态先确定，谁就先排队；同一轮微任务中，它们严格按 FIFO（先进先出）执行。
微任务入队时机取决于 Promise 状态何时确定
Promise 构造函数内的同步代码立即执行，但 .then() 回调不会立刻运行。只有当该 Promise 的状态变为 fulfilled 或 rejected 时，其已注册的 .then() 才被推入微任务队列。
- 外层 Promise 状态一确定，它的第一个
.then()就入队（哪怕里面又创建了新 Promise） - 嵌套 Promise 的
.then()要等它自己 resolve 后才入队，这个时间点通常晚于外层第一个.then()的注册，但可能早于或晚于外层第二个.then() - 例如：
p.then(a).then(b)中，a必须执行完并返回值（或 Promise），b才能被调度；若a内部return Promise.resolve().then(c)，则c和b都是微任务，但c入队更早（因内层 Promise 先 resolve），所以通常先执行c，再执行b
嵌套 then 不会“打断”当前微任务流，但会延后后续外层 then
一个 .then() 回调函数体是同步执行的，但它内部返回的新 Promise 是否已决议，决定了后续 .then() 的入队节奏。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 如果嵌套 Promise 是同步 resolve（如
new Promise(r => r())），它的.then()会在当前微任务阶段末尾入队，仍属本轮清空范围 - 如果嵌套 Promise 是异步 resolve（如
setTimeout(() => resolve(), 0)），它的.then()会等到下一轮事件循环才入队 - 外层链式
.then()的执行必须等待前一个.then()返回的 Promise 状态确定——也就是说，嵌套 Promise 的延迟会“拖住”外层后续.then()的入队，哪怕外层语法上写得更靠前
所有微任务共享同一队列，顺序由插入时刻决定
Promise.then()、queueMicrotask()、MutationObserver 回调共用一个微任务队列，插入顺序即执行顺序。
立即学习“Java免费学习笔记（深入）”；
- 假设外层
p.then(A)先执行，在 A 中同步创建Promise.resolve().then(B)，那么 B 会紧接在 A 后面入队 - 若此时外层还有
p.then(C)（即p.then(A).then(C)），C 的入队要等 A 执行完并返回 Promise，因此 C 实际入队时间晚于 B - V8 引擎中 Promise 回调略早于
queueMicrotask，但规范只保证同类型 FIFO；跨类型顺序不应依赖
典型执行节奏：同步 → 微任务批量清空 → 下一轮宏任务
一次事件循环中，微任务队列会持续清空直到为空——这意味着，只要新微任务在本轮清空过程中被加入（比如某个 .then() 回调里又生成了新的 .then()），它就会被紧接着执行，无需等下一轮。
- 例如：
Promise.resolve().then(() => console.log(1)).then(() => Promise.resolve().then(() => console.log(2)))输出 1 → 2，因为第二个.then()的回调在第一个执行时才创建并入队，但仍属本轮微任务 - 但
Promise.resolve().then(() => console.log(1)).then(() => setTimeout(() => console.log(2), 0))中，setTimeout是宏任务，2 一定在 1 之后、且等到下一轮宏任务才输出 - 嵌套越深，微任务入队层级越多，但只要不引入宏任务，全部都压在一次微任务清空阶段完成
