为什么Promise.all传入超10个混合类型Promise会报No overload matches this call错误？

为什么第11个元素开始触发报错 #

TypeScript 为了让Promise.all能保留输入元素的顺序类型（返回对应长度的元组类型，而非直接拍扁为联合类型数组），内置定义了10个固定长度的泛型重载，分别适配1~10个元素的输入场景。
当输入数组元素≤10个时，会匹配到对应长度的元组重载，每个元素的类型独立推导，不会互相约束。一旦元素超过10个，固定元组重载匹配失败，会 fallback 到通用的迭代器重载：

all<T>(values: Iterable<T | PromiseLike<T>>): Promise<T[]>;

这时候 TypeScript 需要把数组内所有 Promise 的返回值合并推导为统一的泛型T，就会触发后续的类型兼容校验。

类型报错的根本原因 #

你定义的Image、Image2、Image3三个类虽然都有同名的protected data属性，但互相之间没有继承关系。TypeScript 对包含 protected 成员的类型兼容性有严格要求：只有存在父子继承关系的类，才允许兼容同名 protected 成员的类型，平级类即使结构完全一致也不兼容。
当走通用重载推导统一T时，TypeScript 会优先取第一个元素的返回类型Image作为候选T，后续的Image2、Image3因为和Image不兼容，就抛出了类型错误。
如果所有元素都是同类型的 Promise，推导出来的T就是这个唯一类型，自然不会报错，这就是全用Image3时超过10个元素也正常的原因。

和PromiseLike、ES库版本的关系 #

这个问题和PromiseLike本身无关，PromiseLike只是 TypeScript 定义的用来兼容不同 Promise 实现的通用接口，没有触发这个问题。
也和lib.es2015.iterable的版本无关，是 TypeScript 类型系统的设计取舍：为了避免类型定义体积过大、拖慢编译速度，官方默认只提供10个元素的Promise.all元组重载，目前最新版 TypeScript 也没有修改这个设计，毕竟超过10个不同类型元素的Promise.all场景在实际开发中占比极低。

除了嵌套Promise.all的其他解决方案 #

• 主动指定通用重载的泛型参数，显式声明允许的返回值联合类型：

await Promise.all<Image | Image2 | Image3>([
  // 所有Promise元素
])

• 给任务数组加显式类型标注：

const tasks: (Promise<Image> | Promise<Image2> | Promise<Image3>)[] = [
  // 所有Promise元素
]
await Promise.all(tasks)

内容的提问来源于stack exchange，提问作者koalaok