Promise.all([]) 返回一个已解决的 promise，但 Promise.race([]) 返回一个挂起的 promise。他们为什么不同？

Question

如果使用非空数组调用 Promise.all 或 Promise.race ，它们将返回一个挂起的承诺：

console.log(Promise.all([1]));
// prints Promise {<pending>}
console.log(Promise.race([1]));
// returns Promise {<pending>}

如果使用空数组调用 Promise.race，它会返回一个挂起的承诺：

console.log(Promise.race([]));
// prints Promise {<pending>}

但是如果 Promise.all 用一个空数组调用，它会返回一个已经解决的承诺：

console.log(Promise.all([]));
// prints Promise {<resolved>: Array(0)}

为什么 Promise.all 函数设计成这样？不一致似乎没有充分的理由，但也许我错过了一些东西。

Answer 1

来自EMCA 脚本规范Promise.race()：

如果 iterable 参数为空或者如果 iterable 中的任何承诺都没有解决，则此方法返回的挂起承诺将永远不会解决

该Promise.all()规范是不那么容易在这方面跟进，但基本上当你传递一个空数组，这与他们用来指那些为开出remainingElementsCount的0可以让它立即解决。

当您将一个值传递给它时Promise.all([1])，它可能会包装该值Promise.resolve()，然后跟踪.then()处理程序，该处理程序将在下一个滴答声中解析，因此console.log(Promise.all([1]))显示它在下一个滴答声之前仍处于挂起状态。

从逻辑上讲，这是有一定道理的。 Promise.race()应该解析为要解析的第一个承诺的值，但是如果您不传递任何内容，则确实没有第一个解析的值。唯一的其他选择是拒绝或解决undefined或抛出无效使用异常。我不太确定为什么设计师选择他们所做的结果而不是这些其他选择，但至少在规范中清楚地详细说明了这一点。

Promise.all()，另一方面，可以很好地解析为空数组，这是传递空数组的合乎逻辑的结果。

为什么 Promise.all 函数设计成这样？

要真正“了解”设计者的逻辑，您必须询问他们中的一个人，或者已经参与讨论或找到讨论逻辑的邮件列表讨论。

但是，可以提出一个论点，即如果您有一个可变长度数组，您想等待它完成，Promise.all()那么无论数组中有 20 个项目还是 0 个项目，该函数都应该可以工作。对于0长度数组，它只会在下一个滴答声中立即解析，这将既有用又一致，因为没有要等待的承诺，并且有一个适合且一致的解析值（一个空数组）。

ES6 话题讨论

这是一个Promise.race()从未解决的开发讨论的链接：https : //github.com/domenic/promises-unwrapping/issues/75。肯定有人不同意当前的实施。

我个人的观点（在这个主题的各种讨论中与其他一些人分享）是它应该抛出异常，因为它基本上是一个无效的条件，从开发的角度来看，“快速且明显地失败”比无限的承诺要好得多。但是，显然有更多的人喜欢它的样子。

在蓝鸟文档建议使用它们Promise.any()来代替Promise.race()，部分原因是因为它没有这种行为。