TypeScript v4.0.2中array.reduce()返回类型判定及异常咨询

嘿，这个问题戳中了TypeScript 4.0.x版本里数组reduce方法类型推断的一个坑，我来帮你把根源和各个方案的原理讲透：

核心问题：为什么reduce的返回类型被判定为IOldType？ #

在你的例子里，明明reducer函数返回的是INewType[]，初始值也是INewType[]，但TS却错误地推断reduce的返回类型为IOldType，本质上是TS 4.0.2的类型推断逻辑缺陷：

TypeScript中数组reduce的类型定义（简化版）是：

interface Array<T> {
  reduce<U>(
    callback: (acc: U, curr: T) => U,
    initialValue: U
  ): U;
}

理论上TS应该通过initialValue的类型（INewType[]）和回调的返回类型（INewType[]）推断出U = INewType[]，最终返回U类型。但在4.0.2版本中，当数组元素类型T（这里是IOldType，带[key: string]: any索引签名）与U类型（INewType[]，数组也是带索引签名的对象）存在“弱兼容”时，TS的推断逻辑会错误地优先把U推断为T（IOldType），导致返回类型完全偏离预期。

为什么会有弱兼容？因为IOldType的索引签名允许任意字符串键对应any值，而数组（INewType[]）作为对象，其数字索引会被转为字符串索引，所以TS认为数组可以赋值给IOldType，这就给推断逻辑制造了混淆。

三个临时方案的原理拆解 #

1. 使用类型断言as INewType[] #

这个方案本质是强制告诉TS忽略自身的推断结果，直接使用你指定的类型。好处是快速解决错误，但正如你担心的，它完全跳过了TS的类型检查——如果哪天reducer函数真的返回了不符合INewType[]的值，TS也不会提醒你，埋下类型安全隐患。

2. 在IOldType中添加无关可选属性解决问题 #

这招能生效，是因为它打破了IOldType和INewType[]之间的弱兼容关系。当你给IOldType加一个数组没有的可选属性（比如foo?: number），TS就不再认为数组可以赋值给IOldType了，此时推断逻辑会被迫回到正确的轨道：根据初始值和回调返回类型推断U = INewType[]，自然就不会报错了。

举个例子，修改后的接口：

interface IOldType { 
  [key: string]: any;
  foo?: number; // 新增无关可选属性
}

此时TS无法再把INewType[]和IOldType混淆，推断逻辑恢复正常。

3. 省略累加器类型或设为any #

这个方案是通过弱化类型约束来让TS的推断“放弃抵抗”：如果把acc的类型设为any，或者省略类型让TS推断，TS会认为回调的返回类型可以是任意值，自然不会和数组元素类型产生冲突。但代价是完全丧失了类型安全——acc的类型不受约束，你在reducer里对acc做的操作都不会有类型检查，很容易引入bug。

正确的、类型安全的解决方案 #

既然临时方案都有缺陷，最稳妥的办法是显式指定reduce方法的泛型参数U，直接告诉TS返回类型应该是什么，从根源上避免推断错误：

const newData: INewType[] = oldData.reduce<INewType[]>(reducerFunction, initialValue);

通过<INewType[]>显式指定泛型参数，TS会严格按照这个类型来校验回调函数和初始值，既保证了类型安全，又解决了推断错误的问题。

另外，如果你能升级TypeScript版本到4.1及以上，这个推断bug已经被修复了——新版本的TS在处理reduce的类型推断时，会优先考虑初始值和回调的返回类型，不会再出现这种错误的类型推断。

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