TypeScript中抛出错误的函数：never与void的类型差异、实践影响及最佳实践问询

阿华AIGC实验室

2026-3-31

这问题问得特别到位——很多刚接触TypeScript的开发者都会疑惑，既然两种写法都“能跑”，为啥还要纠结用never还是void？咱们从你关心的几个维度慢慢拆解：

从类型系统视角看，`never`和`void`的核心差异

先把最本质的区别说透：

void表示函数能正常执行结束，但没有返回值。比如普通的日志函数，执行完就完成了，只是不返回任何数据；
never表示函数永远不会正常完成——要么抛出错误直接中断执行流，要么进入无限循环卡死，程序的执行逻辑到这里就彻底终止了。

TypeScript的类型系统对二者的处理逻辑完全不同：

void是一个“存在的空类型”，你可以把它理解成“没有返回值，但流程能走完”；
never是“不存在的类型”——它是所有类型的子类型，但没有任何类型能赋值给它（除了它自己），相当于类型系统里的“终止符”。

举个直观的代码例子：

// void的典型场景：执行完就结束，无返回
function logInfo(msg: string): void {
  console.log(`Info: ${msg}`);
}

// never的典型场景：永远走不到函数末尾
function throwFatalError(msg: string): never {
  throw new Error(`Fatal: ${msg}`);
}

对类型收窄与控制流分析的关键影响

TypeScript的控制流分析会根据函数的返回类型，自动推断后续代码的合法性——这也是never最实用的地方之一。

比如下面的场景，用never能让TS自动排除不可能的分支，精准收窄类型：

function getValidValue(): string | never {
  // 50%概率返回字符串，50%概率抛错
  return Math.random() > 0.5 ? "valid-data" : throwFatalError("invalid");
}

function processValue() {
  const data = getValidValue();
  // TS能确定data一定是string，因为throwFatalError返回never，会被从联合类型中排除
  console.log(data.toUpperCase()); // 完全合法，无类型错误
}

但如果把throwFatalError的返回类型改成void，TS的分析逻辑就会出错：

function throwFatalErrorVoid(msg: string): void {
  throw new Error(`Fatal: ${msg}`);
}

function getValidValueVoid(): string | void {
  return Math.random() > 0.5 ? "valid-data" : throwFatalErrorVoid("invalid");
}

function processValueVoid() {
  const data = getValidValueVoid();
  // TS会认为data可能是void，调用toUpperCase就会报错
  console.log(data.toUpperCase()); // 错误：类型“string | void”上不存在属性“toUpperCase”
}

这里的核心区别是：never会告诉TS“这个分支的执行流彻底终止了”，所以不会被当成合法的类型分支；而void会被TS当成“一个有效的空分支”，导致后续类型推断出现偏差。

用`void`替代`never`可能引发的潜在bug

最典型的坑就是穷尽性检查失效——这是大型项目中很容易出现的隐蔽bug。

比如我们用联合类型定义业务枚举，然后用switch处理所有分支：

// 定义水果类型
type Fruit = "apple" | "banana";

// 用never做穷尽性检查：如果传入的参数不是Fruit的合法值，直接抛错
function assertNever(value: never): never {
  throw new Error(`Unexpected value: ${value}`);
}

function handleFruit(fruit: Fruit) {
  switch (fruit) {
    case "apple":
      console.log("处理苹果");
      break;
    case "banana":
      console.log("处理香蕉");
      break;
    default:
      // TS会知道default分支永远不会走到（因为Fruit只有两个值）
      // 如果后续Fruit新增了"orange"，TS会立刻报错，提醒我们处理新分支
      assertNever(fruit);
  }
}

如果把assertNever的返回类型改成void，那么当我们后续给Fruit新增"orange"类型时，TS不会在default分支抛出任何错误——因为void允许函数正常执行，TS会认为default分支是合法的，这样就会漏掉对新类型的处理，直到运行时才会暴露问题。

语义正确性与大型代码库的深层价值

这部分其实是最佳实践的核心：

语义准确性：用never能精准传达函数的意图——“调用我之后，程序的执行流就终止了”，其他开发者看到这个类型就能立刻明白函数的作用，不需要读具体实现；而void的意图是“调用我之后，啥也不返回，程序继续走”，语义上完全不匹配抛错函数的行为。
大型项目的可维护性：在多人协作的大型代码库中，类型的准确性直接影响重构成本和bug率：
- 当你重构一个返回never的函数时，如果不小心让它能正常返回了，TS会立刻报错（因为never不能赋值给其他类型）；
- 类型系统能帮你自动捕获执行流的异常分支，避免逻辑漏洞；
- 统一的类型约定能让团队所有人对函数行为形成共识，减少沟通成本。