未初始化变量绕过TypeScript strictNullChecks的原因问询

开启strictNullChecks选项后，以下几种未初始化变量的场景不会触发TypeScript编译器错误，仅会在运行时抛出异常：

场景1：顶层未初始化变量调用方法 #

let foo: string;
function test() {
  console.log(foo.trim())
}
test()

预期编译器提示'foo' is possibly 'undefined'，但实际仅运行时出现TypeError: Cannot read properties of undefined (reading 'trim')。

场景2：跨模块引入未初始化变量调用方法 #

module1.ts

export let foo: string;

module2.ts

import { foo } from './module1';
console.log(foo.trim());

同样无编译错误。

场景3：嵌套函数访问外层未初始化变量 #

function test() {
  let foo: string;
  function test2() {
    console.log(foo.trim())
  }
}
test()

也未触发编译错误。

TypeScript默认不对这些场景做检测，核心源于语言设计的权衡：

• 变量初始化的不确定性：顶层变量、跨模块变量可能在其他代码路径中被初始化——比如顶层变量可能在脚本后续代码赋值，跨模块变量可能被其他导入该模块的文件赋值。编译器无法追踪所有潜在的赋值场景，强行报错会过度约束代码，牺牲灵活性。

• 嵌套函数的执行时机不可控：嵌套函数可能在外部变量赋值后才被调用，编译器无法静态确定函数的执行顺序。如果强制报错，会误判很多合法代码——比如开发者可能在定义test2后、调用它之前给foo赋值，这种场景下代码完全合法，编译器无法区分“必然未初始化访问”和“可能初始化后访问”的情况。

• 兼容JavaScript生态：TypeScript的核心目标之一是兼容现有JavaScript写法，而JS允许先声明变量后赋值的模式。强制检测这类场景会导致大量JS代码迁移到TS时出现不必要的错误，大幅提升迁移成本。

如果需要强制检测这类场景，可以手动将变量类型显式声明为string | undefined，结合strictNullChecks就能让编译器触发错误。

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