TypeScript对象字面量含函数时经泛型处理传入Object.fromEntries报类型错误

这个报错本质是TypeScript 4.2-4.5版本存在的泛型推导优先级错位的已知缺陷，触发逻辑可以拆解为三层：

• 调用链的上下文类型反向推导要求：Object.fromEntries是泛型方法，要求传入的参数是长度固定为2的元组集合Iterable<readonly [PropertyKey, T]>，TS会将这个元组结构的要求作为上下文类型，反向传递给上游的Array.map回调，要求回调必须返回定长元组，不能返回长度可变的普通数组。
• 泛型推导的双向冲突：当回调内部调用泛型函数id<T>(x: T)时，TS会同时做两类推导：正向从传入的实参推导T的类型，反向从上下文要求的元组占位类型推导T的类型。当传入的实参是带方法简写的对象字面量时，TS会错误地把反向推导得到的无约束占位类型作为T的最终值，反过来要求正向传入的实参必须匹配这个任意占位类型，最终抛出“实参无法匹配任意T”的类型不兼容报错。
• 不同场景的差异解释：
  • 直接写对象字面量不经过泛型函数时，没有双向推导的冲突，TS会直接把数组字面量推导为定长元组，满足Object.fromEntries的入参要求，因此obj1正常。
  • 经过泛型函数但对象成员是普通属性（非方法简写）时，TS的推导优先级逻辑正常，会用正向传入的实参类型作为T的推导结果，不会触发反向推导的抢占问题，因此obj3正常。

• 显式标注返回值为定长元组，消除推导歧义
  直接给map回调返回的数组加as const断言，或者显式指定map的返回泛型，让TS明确知道返回的是固定长度的元组，不会和泛型函数的推导产生冲突：

  const obj2 = Object.fromEntries(keys.map(k => [
    k, 
    id({test() {}})
  ] as const))
  

• 调整实际业务中泛型函数的签名，增加泛型约束
  你实际业务中使用的签名为<T>(x: T) => T & SomeExtraFields，只需要给泛型T增加明确的对象约束，就能强制TS使用正向推导的实参类型作为T的取值，避免反向占位类型的抢占：

  // 调整后的签名
  function withExtra<T extends object>(x: T): T & SomeExtraFields {
    return Object.assign(x, /* 额外字段逻辑 */)
  }
  

• 临时绕开方法简写的推导bug
  如果不想调整原有逻辑，可以把对象里的方法简写改成属性赋值的写法，这种形式的对象字面量不会触发TS的推导优先级错误：

  // 把 test() {} 改成 test: () => {}
  const obj2 = Object.fromEntries(keys.map(k => [
    k, 
    id({test: () => {}})
  ]))
  

• 升级TypeScript版本
  这个推导错位的问题是TS 4.2-4.5版本的已知缺陷，在TS 4.6及以上版本已经被官方修复，升级到当前的稳定正式版本可以从根源解决这类问题。

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