TypeScript显式联合类型变量被错误收窄是否为编译器Bug？

TypeScript的控制流分析会根据代码执行路径中的赋值、条件判断等操作，对变量的类型进行收窄——哪怕变量有显式的联合类型注解，编译器也会跟踪当前执行点的具体类型，这是设计上的取舍，而非Bug。

核心原因拆解 #

1. 即时赋值的类型收窄
   当你执行let val: number | null = null;时，编译器明确知道此时val的具体值是null，所以后续直接赋值给val2时，会将val2的类型推断为null（因为val2是const，赋值后不会再变化）。这是合理的类型推断，符合变量当前的实际状态。

2. 跨函数的类型跟踪限制
   对于setValToNumber()这类同步函数调用，TypeScript的控制流分析不会跨函数体跟踪变量的修改。哪怕函数内部确实修改了val的值，编译器也不会主动分析函数内部的逻辑来更新外部变量的类型——这是为了避免编译复杂度指数级上升（比如函数可能被多处调用、包含条件分支、甚至被动态修改），保证编译效率。

   所以在调用setValToNumber()后，编译器仍然认为val保持着之前收窄的null类型，导致val3的类型被推断为null，哪怕运行时实际值是数字。

3. 函数返回值的推断逻辑
   在getVal函数中，编译器基于当前控制流的类型分析，认为val是null类型，因此推断函数返回类型为null。同样是因为编译器不会跨函数分析setValToNumber对val的修改影响。

可行的解决方案 #

• 显式指定函数返回类型：这是最稳妥的方式，直接告诉编译器函数的返回类型是联合类型，比如：

  const getVal = (): number | null => {
    let val: number | null = null;
    const setValToNumber = () => { val = 0; };
    setValToNumber();
    return val;
  }
  const val = getVal(); // 类型为number | null
  

• 使用类型守卫重新确认类型：如果需要在调用函数后让编译器识别变量的实际类型，可以添加类型判断：

  setValToNumber();
  if (val !== null) {
    const val3 = val; // 此时val3类型为number
  }
  

• 避免跨函数修改变量：尽量在同一控制流内完成变量的赋值和使用，减少编译器无法跟踪的场景。

内容的提问来源于stack exchange，提问作者broken-e