TypeScript引入never类型的原因及显式声明必要性探讨

Great question! I’ve wrestled with this exact confusion myself—let’s break down why never isn’t just a compiler quirk, but a practical tool that solves real pain points in TypeScript codebases.

1. Enforcing Exhaustiveness Checks (The Big One) #

This is the most critical use case for explicit never. When working with union types (like enums or string literals), never lets you guarantee that you’ve handled every possible branch of logic. If you later add a new member to the union, the compiler will throw an error to alert you of the missing case—something automatic inference alone won’t enforce as intentionally.

Take this example with a fruit type:

type Fruit = "apple" | "banana" | "orange";

function getFruitColor(fruit: Fruit): string {
  switch (fruit) {
    case "apple":
      return "red";
    case "banana":
      return "yellow";
    case "orange":
      return "orange";
    // Explicit `never` forces the compiler to check for unhandled cases
    default:
      const _exhaustiveCheck: never = fruit;
      throw new Error(`Unknown fruit: ${_exhaustiveCheck}`);
  }
}

If you later update Fruit to include "grape", the compiler will immediately flag the default block—because "grape" can’t be assigned to never. This prevents silent failures from unhandled cases.

2. Documenting Unreachable Code Intent #

Explicit never acts as clear documentation for other developers (and future you) that a section of code is intentionally unreachable, not just a mistake.

For example, a function that always throws an error:

// Explicitly says: this function never returns normally
function throwFatalError(message: string): never {
  throw new Error(`FATAL: ${message}`);
}

// Anyone reading this knows the line below will never run
throwFatalError("Something went horribly wrong");
console.log("This is dead code"); // Compiler even flags this as unreachable

Without the explicit never return type, someone might accidentally add a return statement later, breaking the function’s intended behavior.

3. Narrowing Types in Complex Flows #

In nested conditional logic or higher-order functions, explicit never helps the compiler narrow types more reliably. It eliminates ambiguity about what types are possible at a certain code path.

Here’s a result handler example:

type Result<T> = 
  | { type: "success"; data: T }
  | { type: "error"; message: string };

function handleResult<T>(result: Result<T>) {
  if (result.type === "success") {
    processData(result.data);
  } else if (result.type === "error") {
    logError(result.message);
  } else {
    // Explicit `never` confirms no other Result variants exist
    const _unreachable: never = result;
    throw new Error(`Unexpected result: ${_unreachable}`);
  }
}

If you ever add a new variant to Result (like { type: "loading" }), the compiler will catch it immediately in that else block.

4. Preventing Accidental Returns #

For functions that are meant to never return (like infinite loops or fatal error throwers), explicit never prevents accidental return statements that would break the function’s semantics.

// Correct: this loop runs forever, no return
function keepAlive(): never {
  while (true) {
    checkSystemHealth();
  }
}

// Compiler throws an error here: Type 'void' is not assignable to type 'never'
function brokenKeepAlive(): never {
  while (true) {}
  return; // Oops—this shouldn't be here!
}

Without the explicit never type, that accidental return would go unnoticed, changing the function’s behavior.

At the end of the day, never is about turning implicit assumptions into explicit, compiler-enforced guarantees. It’s not just for intellisense—it’s a tool to make your code more robust, self-documenting, and resistant to bugs when types evolve.

内容的提问来源于stack exchange，提问作者Morten H Pedersen