Promise.race 这一 API，许多开发者初看时容易将它与 .then() 混为一谈，认为它也会自动创建微任务。但实际情况并非如此——它本身并不生成微任务，而是同步地监听多个 Promise 中首个状态变化，并将该结果（无论 fulfilled 还是 rejected）直接“透传”给自己的返回 Promise。真正决定调度顺序的关键，在于被 race 的那些 Promise 内部状态变更的时机；而后续的 .then() 回调，依然遵循标准的微任务机制。
Promise.race 并非微任务的引发者
与 .then() 不同，Promise.race() 的调用过程是同步执行的。它不会立即向微任务队列中推送任何回调。它的核心职责只有一个：为传入的每个 Promise 实例注册一个内部的“完成监听器”。一旦其中任意一个 Promise 的状态变为 fulfilled 或 rejected，race 返回的新 Promise 就会以相同的结果立即 settle（即进入 fulfilled 或 rejected 状态）。这个 settle 动作会触发后续链式调用（例如 .then()）的回调——而这些回调，才是真正的微任务。
实际执行顺序由被 race 的 Promise 触发时机决定
race 的“竞速”结果，完全取决于哪个被监听的 Promise 最先完成其状态变更的逻辑。关键要点如下：
- 如果某个 Promise 在构造函数中直接执行
resolve('a')，那么它属于同步 resolve，其.then()回调会在当前宏任务末尾的微任务阶段执行； - 如果另一个 Promise 通过
setTimeout(() => resolve('b'), 0)来执行 resolve，那么它的 resolve 会发生在下一个宏任务中，因此其.then()必然晚于前者； - 因此
Promise.race([syncP, timeoutP])的结果一定是 syncP 的值，并且 race 返回的 Promise 的.then()会排在本轮微任务队列的靠前位置。
race 后续的 .then 属于标准微任务
一旦 race 返回的 Promise 状态确定，你对其调用的 .then()、.catch() 就与普通 Promise 完全一致：回调会被放入微任务队列，等待当前同步代码执行完毕后统一清空。例如：
console.log('1');
Promise.race([
Promise.resolve('fast'),
new Promise(r => setTimeout(() => r('slow'), 10))
]).then(v => console.log('2:', v));
console.log('3');
输出顺序是 1 → 3 → 2: fast，因为 .then() 作为微任务，严格遵循“同步 → 微任务 → 宏任务”的事件循环优先级规则。
常见误用：将 race 当作“强制提前终止”工具
需要特别注意的是，race 并不会取消或中断其他正在运行的 Promise。它仅关心“谁最先完成”，其余 Promise 仍会继续执行，可能因此产生副作用（例如多余的网络请求、未清理的定时器）。若要实现真正的取消行为，应配合 AbortController 或自行设计可取消的逻辑，而不能依赖 race 本身。
