TypeScript如何避免元组联合退化为联合元组导致类型收窄失效

首先明确结论：你遇到的类型推导行为是TypeScript的官方预期设计，并非实现bug。

底层逻辑说明 #

TypeScript的类型系统有两个固定规则，刚好可以解释两种写法的表现差异：

• 类型收窄的生效前提，是守卫逻辑作用于同一个可追踪的内存绑定。当你对某个引用做分支判断时，TS会直接从这个引用的类型联合中剔除不匹配的分支，完成类型收窄。
• 数组解构操作会切断不同解构位置之间的类型关联。当你写出const [val, err] = myFunc()时，TS不会将val和err识别为来自同一个原元组的关联值，而是会针对每个解构位置，收集原联合类型中所有可能出现在该位置的类型，取并集作为独立变量的类型：
  • 对于原联合[Val, null] | [null, Error]，第0位在两个分支中分别出现了Val和null，因此解构出的val会被推导为Val | null
  • 第1位在两个分支中分别出现了null和Error，因此解构出的err会被推导为null | Error
    此时val和err是两个完全独立的顶层绑定，TS的类型系统不知道二者存在互斥关系——也就是它不会意识到"err有值时val必然为null、val有效时err必然为null"的对应关系，因此后续哪怕判断了err存在，也无法反过来修正val的类型。

对比对象形式的可辨识联合场景：你始终在对res这个单一引用做判断，if (res.type === 'Error')的守卫会直接将res的类型从联合中收窄到Error分支，自然可以在后续代码中正确推导Success分支下的字段类型，完全不会出现关联断裂的问题。

可落地的实现方案 #

要实现Go风格的优雅错误返回体验，同时保证类型推导准确，有两个低侵入的常用方案：

1. 延迟解构时机，基于原引用做类型守卫
   不要拿到返回值后第一时间就完成全量解构，而是先对原元组的对应位置做守卫判断，完成分支收窄后再解构取值：

   const res = myFunc(); // 原始类型为 [Val, null] | [null, Error]
   if (res[1]) { // 基于原引用的第1位做错误判断
     handle(res[1]);
     return;
   }
   // 此时res已经被正确收窄到[Val, null]成功分支
   const [val] = res;
   doSomethingWith(val); // 类型推导准确，无空值报错
   

2. 封装自定义类型守卫明确分支边界
   如果需要更清晰的代码语义，可以为结果类型定义自定义类型守卫，主动向TS声明两个分支的判别条件：

   // 定义统一的结果类型
   type Ok<T> = [T, null];
   type Err<E = Error> = [null, E];
   type Result<T, E = Error> = Ok<T> | Err<E>;
   
   // 自定义类型守卫，明确成功分支的判别逻辑
   function isOk<T, E>(res: Result<T, E>): res is Ok<T> {
     return res[1] === null;
   }
   
   // 业务代码使用
   const res = myFunc();
   if (!isOk(res)) {
     handle(res[1]);
     return;
   }
   const [val] = res; // val被正确推导为Val类型
   doSomethingWith(val);
   

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