严格模式

是什么，为什么存在

TypeScript 的 严格模式（strict mode） 不是一种运行模式，而是一组互相关联的静态检查。配置 strict: true 后，编译器会对空值、函数参数、类字段、this、捕获变量和未能推断类型的位置采用更保守的规则。

TypeScript 必须接纳大量已有 JavaScript，因此它允许项目逐步增加类型约束。宽松配置可以让旧代码先编译，却也会把一些未经证明的假设当成合法代码。例如，查找操作可能没有结果，回调可能只接受更窄的输入，类字段也可能在读取时仍未初始化。

严格模式把这些假设变成编译错误，让修复发生在代码运行之前。你会在新建 tsconfig.json、接管旧项目、升级编译器，或者为缺少类型声明的库补边界时遇到它。它并不要求每个局部变量都写注解；只要推断结果足够明确，代码仍可保持简洁。

这些保证在编译阶段结束。TypeScript 会进行 类型擦除（type erasure） ，因此生成的 JavaScript 不会携带接口、联合类型或大多数检查。严格模式能约束经过检查的源码，却不能证明网络响应、文件内容或 JavaScript 调用方送来的值符合声明。

工作原理

strict 是一个总开关。TypeScript 6 会通过它启用九个相关选项，但你仍可在同一份配置中把某个子选项显式设为 false。后写的例外不会关闭总开关的其他部分。

{
  "compilerOptions": {
    "strict": true
  }
}

TypeScript 6 中的严格选项如下。以后版本可能在 strict 下加入更严格的检查，所以编译器升级有可能带来新的诊断。

这些选项改变的是编译器需要什么证据。strictNullChecks 会让查找函数的 undefined 出现在返回类型中；一次存在性检查随后触发 控制流收窄（control-flow narrowing） 。strictPropertyInitialization 则分析构造路径，而不是等对象第一次使用时再发现字段缺失。

noImplicitAny 只禁止编译器悄悄推断出的 any，并不禁止作者显式写 any。类似地，useUnknownInCatchVariables 会保护默认的捕获变量，但 catch (error: any) 仍能主动退出检查。严格模式提高默认门槛，无法阻止代码明确绕过门槛。

示例

下面四个程序都使用 TypeScript 6.0.3 以 strict: true 完成类型检查，再由 Node 24 的 tsx 执行。它们依次展示空值、回调参数、运行时边界和内置迭代器。

收窄可空查找结果

数组的 find() 可能返回 undefined。严格空值检查把这种可能性保留在类型中，因此读取账户属性前必须处理未找到的分支。

account === undefined 之后，编译器知道剩余路径中的 account 是 Account。displayName 仍可能为 null，所以空值合并运算符提供与数据模型一致的后备标签。

这里没有使用非空断言。写成 findAccount(id)!.displayName 虽然能消除诊断，却会在编号不存在时重新引入运行时错误。

保持回调参数安全

函数赋值必须考虑调用方允许传入的全部值。接受任意 Animal 的函数可以放到只会收到 Dog 的位置；只会处理 Dog 的函数不能冒充通用处理器。

interface Animal {
  name: string;
}

interface Dog extends Animal {
  bark(): string;
}

type AnimalHandler = (animal: Animal) => string;
type DogHandler = (dog: Dog) => string;

const describeAnimal: AnimalHandler = (animal) => `Checking ${animal.name}`;
const describeDog: DogHandler = (dog) => `${dog.name} says ${dog.bark()}`;

const handleDog: DogHandler = describeAnimal;

// @ts-expect-error 只处理 Dog 的函数不能安全处理所有 Animal。
const handleEveryAnimal: AnimalHandler = describeDog;

const pixel: Dog = { name: "Pixel", bark: () => "woof" };
console.log(handleDog(pixel));
console.log(describeDog(pixel));

Checking Pixel
Pixel says woof

@ts-expect-error 在这里是一项编译测试：如果不安全赋值不再产生诊断，指令本身就会报错。示例没有调用被拒绝的赋值，因此运行结果只来自两个安全调用。

这条规则属于 函数参数变型（function parameter variance） 。方向容易看反：判断的不是函数名称里写了哪种动物，而是接收该函数的调用方以后可以传入什么。

验证边界并初始化字段

严格检查无法验证 JSON，但可以迫使边界代码保留未知性。下面先把解析结果赋给 unknown，检查对象形状和领域约束，再创建字段已经完整初始化的实例。

class RetryPolicy {
  constructor(
    readonly endpoint: string,
    readonly maxAttempts: number,
  ) {}
}

function parsePolicy(text: string): RetryPolicy {
  const value: unknown = JSON.parse(text);
  if (
    typeof value !== "object" ||
    value === null ||
    !("endpoint" in value) ||
    !("maxAttempts" in value) ||
    typeof value.endpoint !== "string" ||
    typeof value.maxAttempts !== "number" ||
    !Number.isInteger(value.maxAttempts) ||
    value.maxAttempts < 1
  ) {
    throw new Error("Invalid retry policy");
  }
  return new RetryPolicy(value.endpoint, value.maxAttempts);
}

for (const raw of [
  '{"endpoint":"/v1/retry","maxAttempts":3}',
  '{"endpoint":"/v1/retry","maxAttempts":0}',
]) {
  try {
    const policy = parsePolicy(raw);
    console.log(`policy=${policy.endpoint}:${policy.maxAttempts}`);
  } catch (error) {
    const message = error instanceof Error ? error.message : String(error);
    console.log(`error=${message}`);
  }
}

policy=/v1/retry:3
error=Invalid retry policy

构造函数参数属性在对象返回前完成赋值，所以 strictPropertyInitialization 可以证明两个字段都存在。这里不需要 明确赋值断言（definite assignment assertion） ，也没有一个可被提前读取的半初始化实例。

catch 变量是 unknown，因为 JavaScript 可以抛出字符串、对象或 null，并不只会抛出 Error。instanceof Error 分支保留标准错误消息，后备分支则安全地把其他值转成字符串。

检查迭代器是否结束

内置迭代器的 next() 同时返回完成标记和值。strictBuiltinIteratorReturn 阻止完成分支中的 value 以 any 混入程序，读取前要先判断 done。

function printJobs(jobs: Set<string>): void {
  const iterator = jobs.values();

  while (true) {
    const next = iterator.next();
    if (next.done) break;
    console.log(next.value.toUpperCase());
  }
}

printJobs(new Set(["compile", "test"]));
console.log("done");

COMPILE
TEST
done

检查 next.done 后，TypeScript 能在未完成分支中确定 next.value 是 string。直接访问 jobs.values().next().value.toUpperCase() 会忽略空集合，并在严格检查下暴露出可能的 undefined。

这类诊断常出现在编译器升级之后，因为旧版本曾让内置迭代器的完成值默认为 any。修复应遵守迭代器协议，而不是在 value 后添加 !。

陷阱

修复方法： 让不可信值以 unknown 进入，检查容器类型、必填字段和领域约束，再构造领域对象。类型断言只记录已经完成的证明，不能代替证明。

修复方法： 按错误来源修复：补充边界类型，收窄联合，覆盖缺失分支，或在构造函数中初始化字段。确实需要逃生口时，把它限制在一个小型适配器中，并记录它依赖的运行时条件。

修复方法： 根据项目契约另外评估 noUncheckedIndexedAccess、exactOptionalPropertyTypes 和 noImplicitOverride。它们会带来真实迁移成本，所以应逐项启用并用测试确认行为，而不是把它们误称为 strict 的组成部分。

修复方法： 在持续集成中运行明确的项目命令，例如 tsc -p tsconfig.json --noEmit，并检查 tsc --showConfig -p tsconfig.json 的最终配置。配置使用 extends 时，还要寻找下游对严格子选项的覆盖。

修复方法： 对回调契约使用函数属性，例如 handle: (event: Event) => void，让严格函数检查生效。来自第三方方法的值仍要按其真实输入范围测试，不能只依赖一次结构赋值。

延伸阅读

• TypeScript 配置参考：strict
• TypeScript 配置参考：strictNullChecks
• TypeScript 配置参考：strictFunctionTypes
• TypeScript 配置参考：strictPropertyInitialization
• TypeScript 配置参考：useUnknownInCatchVariables