Promise.then回调天然属于微任务，由规范和引擎自动注册到微任务队列，当前宏任务结束后立即按FIFO顺序执行；同步resolve时回调在脚本末尾入队，异步resolve则在其对应宏任务结束后入队。
Promise 的 then 回调默认就在微任务队列中执行，不需要额外操作 —— 这是 Promise 规范（Promises/A+）和 JavaScript 引擎（如 V8）的底层行为决定的。
为什么 then 回调天然属于微任务？
当 Promise 状态变为 fulfilled 或 rejected 时，所有注册的 then（或 catch、finally）回调不会立即执行，也不会等到下一轮宏任务（如 setTimeout）。它们会被引擎自动放入当前事件循环的**微任务队列（microtask queue）**，并在本轮宏任务结束后、渲染前，按注册顺序依次执行。
如何验证它在微任务队列？
可以借助 Promise.resolve().then() 和 setTimeout 的执行顺序对比来确认：
-
Promise.then()回调总在setTimeout(() => {}, 0)之前执行 -
queueMicrotask()中的回调与then回调处于同一队列，执行时机一致
例如：
console.log(1); Promise.resolve().then(() => console.log(2)); setTimeout(() => console.log(3), 0); console.log(4); // 输出：1 → 4 → 2 → 3
哪些情况会让 then 回调“延迟”进入微任务队列？
它本身不会“等待”，但触发时机取决于 Promise 状态变化的时刻：
- 同步 resolve/reject：then 回调在当前脚本执行完后、下一个宏任务前入队
- 异步 resolve（如在
setTimeout或 fetch 回调中）：then 回调在对应宏任务结束后才被推入微任务队列 - 链式调用中返回新 Promise：上一个 then 的返回值决定下一个 then 的入队时机（比如返回普通值立刻入队；返回 Promise 则等它 settled 后再入队）
不能把它改成宏任务，也不该强行“推迟”
如果你希望回调延后到下一个宏任务，说明你其实需要的是 setTimeout 或 queueMicrotask 的明确调度语义。Promise.then 的设计目标就是微任务 —— 它保障了异步逻辑的可预测性和最小延迟。强行绕过（比如包一层 setTimeout）会破坏 Promise 链的时序一致性，通常不是好做法。
