Promise.resolve()立即返回已解决的Promise，但.then回调仍需等待微任务队列执行；其本质是值包装而非延迟，所有then/catch回调均按规范异步入微任务队列，优先级高于setTimeout等宏任务。
Promise.resolve() 立即返回一个已解决（fulfilled）的 Promise，但它**不会立刻执行后续的 .then 回调**——这些回调会被放入微任务队列，在当前同步代码执行完后、下一次事件循环开始前被调度执行。
Promise.resolve() 的本质是“包装”，不是“延迟”
它只是把传入的值（或 Promise）包装成一个 Promise 实例，并立即进入 fulfilled 状态。但 Promise 的链式处理逻辑（如 .then）必须遵循规范：所有 then/catch 回调都必须异步执行，哪怕 Promise 已经 settled。
- 若传入普通值（如
Promise.resolve(42)），返回的 Promise 立即处于 fulfilled 状态，但.then(() => {...})中的回调仍要等微任务队列轮到它 - 若传入另一个 Promise（如
Promise.resolve(Promise.resolve(100))），它会等待该 Promise 完成后再统一处理，但最终仍走微任务调度流程 - 它不等定时器、不等 I/O、也不触发宏任务；它的“异步性”纯粹来自 Promise/A+ 规范对回调执行时机的强制约定
与 setTimeout 的对比：清晰看到微任务优先级
下面这段代码能直观体现微任务队列的高优先级：
console.log('1');
Promise.resolve().then(() => console.log('2'));
setTimeout(() => console.log('3'), 0);
console.log('4');
// 输出顺序：1 → 4 → 2 → 3
解释：
- '1' 和 '4' 是同步执行；
- Promise.then 回调被推入微任务队列，当前宏任务（脚本执行）结束后立即清空微任务队列 → 输出 '2'；
- setTimeout 回调属于宏任务，排在下一轮事件循环 → 输出 '3'。
链式调用中，每个 .then 都产生新的微任务
即使你连续写多个 .then，它们也不会合并执行，而是逐个入队：
Promise.resolve()
.then(() => { console.log('a'); return 1; })
.then(() => console.log('b'))
.then(() => console.log('c'));
// 输出：a → b → c（全部在同一个微任务阶段依次执行）
注意：
- 每个 .then 返回的新 Promise 会把下一个回调注册为自己的微任务；
- 虽然看起来“串行”，但实际是三个独立微任务，按注册顺序排队；
- 若某个 .then 抛出错误，会跳过后续 .then，转由最近的 .catch 处理（同样走微任务）。
常见误区：Promise.resolve().then 不等于同步执行
有人误以为“既然 Promise 已 resolve，那 .then 就该马上运行”。这是错的——规范明确要求 Promise 回调必须异步化，目的是保证执行时机可预测、避免栈溢出、统一异步模型。
- 即便在严格模式下，
Promise.resolve(1).then(console.log)也绝不会在当前函数调用栈内执行 - 它和
queueMicrotask(() => {...})行为一致，都是微任务；而process.nextTick（Node.js）或queueMicrotask是更底层的等价接口 - React 的 setState、Vue 的 nextTick 等机制，底层也都依赖这一微任务机制来批量更新
