在javascript异步编程中，promise是管理复杂回调和链式操作的核心工具。然而，当涉及多个独立的promise链并发执行时，其内部回调的实际执行顺序往往会超出开发者的直观预期。理解这种行为的关键在于深入了解javascript的事件循环（event loop）和微任务队列（microtask queue）机制。
Promise与微任务队列
JavaScript运行时采用事件循环模型来处理异步操作。当主线程执行同步代码时，遇到的异步任务会被放入不同的任务队列中。Promise的回调（.then(), .catch(), .finally()）被归类为微任务。这意味着它们会在当前宏任务（如主脚本执行）完成后，但在下一个宏任务开始之前执行。微任务队列遵循先进先出（FIFO）的原则。
当一个Promise被解析（resolve）或拒绝（reject）时，其相应的.then()或.catch()回调会被添加到微任务队列中。
独立Promise链的执行顺序问题
考虑以下JavaScript代码片段，其中包含三个独立的Promise链：
Promise.resolve() .then(() => console.log(1)) .then(() => console.log(2)) .then(() => console.log(3)); Promise.resolve() .then(() => console.log(11)) .then(() => console.log(12)); Promise.resolve() .then(() => console.log(111)) .then(() => console.log(122));
许多开发者可能会基于代码的顺序，期望得到类似 1, 11, 111, 2, 3, 12, 122 的输出。然而，实际运行结果可能更接近 1, 11, 111, 2, 12, 122, 3，甚至在不同环境下可能有所不同。这种差异揭示了Promise执行顺序的两个核心规则：
立即学习“Java免费学习笔记（深入）”；
规则一：链内顺序的确定性
在一个单独的Promise链中，.then()回调的执行顺序是严格保证的。例如，在第一个链中，console.log(1) 总是会在 console.log(2) 之前执行，而 console.log(2) 总是会在 console.log(3) 之前执行。这是因为每个 .then() 回调的执行都会解析其返回的Promise，从而将下一个 .then() 回调添加到微任务队列中。
规则二：链间顺序的不确定性
当存在多个独立的Promise链时，它们之间的执行顺序是不确定的。尽管它们在代码中出现的顺序可能暗示了一种优先级，但实际情况并非如此。
让我们逐步分析上述示例的执行过程：
-
初始阶段：
- 主线程执行第一个 Promise.resolve().then(() => console.log(1))，将 () => console.log(1) 添加到微任务队列。
- 接着执行第二个 Promise.resolve().then(() => console.log(11))，将 () => console.log(11) 添加到微任务队列。
- 最后执行第三个 Promise.resolve().then(() => console.log(111))，将 () => console.log(111) 添加到微任务队列。 此时，微任务队列可能包含 [() => console.log(1), () => console.log(11), () => console.log(111)]（顺序由代码书写顺序决定）。
-
微任务队列处理第一批：
- 事件循环从微任务队列中取出 () => console.log(1) 执行，输出 1。此时，它所关联的下一个 .then(() => console.log(2)) 被解析，将 () => console.log(2) 添加到微任务队列的末尾。
- 接着取出 () => console.log(11) 执行，输出 11。它所关联的下一个 .then(() => console.log(12)) 被解析，将 () => console.log(12) 添加到微任务队列的末尾。
- 接着取出 () => console.log(111) 执行，输出 111。它所关联的下一个 .then(() => console.log(122)) 被解析，将 () => console.log(122) 添加到微任务队列的末尾。 此时，微任务队列可能包含 [() => console.log(2), () => console.log(12), () => console.log(122)]。
-
微任务队列处理第二批：
- 事件循环继续从微任务队列中取出并执行回调。例如，它可能按 () => console.log(2) -> () => console.log(12) -> () => console.log(122) 的顺序执行，分别输出 2, 12, 122。
- 在执行 () => console.log(2) 后，下一个回调 () => console.log(3) 会被添加到微任务队列。
- 当队列中只剩下 () => console.log(3) 时，它会被执行，输出 3。
最终输出 1, 11, 111, 2, 12, 122, 3 就是这种机制的一个可能结果。关键在于，当多个Promise在同一轮事件循环中解析，并将它们的后续 .then() 回调添加到微任务队列时，这些回调在队列中的具体插入位置（相对于彼此）可能受到JavaScript引擎内部调度和优化的影响，导致它们之间的相对顺序不完全可预测。
示例验证：多达45种可能的排列
为了进一步证明这种不确定性，我们可以编写一个脚本来生成所有可能的排列，并根据Promise链的内部规则进行验证。虽然具体的排列代码在此不赘述，但其核心思想是：
- 定义所有可能的输出元素（如 1, 2, 3, 11, 12, 111, 122）。
- 定义Promise链的内部顺序规则（例如，1 必须在 2 之前，11 必须在 12 之前等）。
- 生成所有这些元素的排列组合。
- 过滤掉不符合内部顺序规则的排列，剩下的就是有效的可能输出。
通过这种方式，可以发现针对上述代码，符合所有内部规则的有效输出排列可能多达几十种（例如，45种），这强有力地证明了独立Promise链之间执行顺序的不确定性。
最佳实践与注意事项
- 避免依赖独立Promise链的精确交错顺序： 如果你的业务逻辑依赖于多个独立Promise链之间精确的执行顺序，那么你的设计可能存在缺陷。JavaScript引擎不会为你保证这种顺序。
-
明确控制依赖关系： 如果某个Promise链的执行必须等待另一个Promise链完成后才能开始，或者需要它们的并发结果，请使用适当的Promise组合器：
- Promise.all()： 当你需要等待所有Promise都成功完成，并获取它们的结果数组时。
- Promise.race()： 当你只关心哪个Promise最先完成（无论成功或失败）时。
-
链式调用： 如果一个操作的输入依赖于前一个操作的输出，则应将它们明确地链式连接起来。
// 明确的依赖关系 Promise.resolve() .then(() => console.log(1)) .then(() => console.log(2)) .then(() => { // 在这里启动第二个链，确保它在第一个链的特定点之后开始 Promise.resolve() .then(() => console.log(11)) .then(() => console.log(12)); }) .then(() => console.log(3));
- 理解微任务队列的本质： 记住微任务队列是FIFO的，但不同来源（即不同Promise链）的回调被添加到队列中的时机可能会有细微差别，导致最终的全局顺序不确定。
总结
JavaScript Promise在链内保证严格的执行顺序，但对于多个独立的Promise链而言，其回调在微任务队列中的交错执行顺序是不可预测的。这种不确定性源于JavaScript事件循环和微任务队列的调度机制。作为开发者，我们不应依赖于这种未明确保证的顺序。相反，当需要特定执行顺序或结果组合时，应主动使用Promise的链式调用、Promise.all() 或 Promise.race() 等工具来明确管理异步操作的依赖关系和并发行为，从而编写出健壮且可预测的异步代码。
