TypeScript 中 any、unknown、void、never、null 和 undefined 的区别

TypeScript 中有一些特殊类型很容易混淆。掌握它们的边界，是写出安全代码的重要基础。

any：绕过类型检查

any 表示任意类型。它很方便，但会关闭类型检查。

let value: any = 42;
value = "hello";
value.toFixed();

更危险的是，any 可以赋值给任何类型。

let input: any = 9;
let name: string = input; // 可以编译，但不安全

因此，除非在迁移旧代码或处理极不确定的数据，否则不要随意使用 any。

unknown：更安全的不确定类型

unknown 也表示不确定类型，但使用前必须先做类型检查。

let value: unknown = "hello";
 
if (typeof value === "string") {
  console.log(value.toUpperCase());
}

如果你只是想表达“我现在还不知道它是什么”，优先用 unknown 而不是 any。

void：没有返回值

void 常用于函数返回值，表示调用者不应该依赖它的返回结果。

function log(message: string): void {
  console.log(message);
}

never：永远不会正常结束

never 表示函数不会正常返回，常见于抛错或无限循环。

function fail(message: string): never {
  throw new Error(message);
}

它也常用于穷尽检查。

type Status = "success" | "error";
 
function handle(status: Status) {
  switch (status) {
    case "success":
      return "ok";
    case "error":
      return "failed";
    default:
      const exhaustive: never = status;
      return exhaustive;
  }
}

null 与 undefined

undefined 表示未赋值，null 表示显式为空。

开启 strictNullChecks 后，null 和 undefined 不能随便赋给其他类型。

let age: number | null | undefined;
age = 18;
age = null;
age = undefined;

严格空值检查可以显著减少空指针类错误。

延伸理解

复习这篇时，不要只记住名词，要把重点放在 any、unknown、void、never、null、undefined 和类型收窄的安全边界。这类知识如果只停留在定义层面，很容易在面试或项目中答得很散。更好的理解方式是把它放进一个具体场景：谁在调用它，输入从哪里来，失败后谁负责恢复，数据或状态会不会被重复处理。

TypeScript 的价值是把运行时不确定性尽量前移到开发阶段，但它不能替代运行时校验。
类型设计应优先描述业务约束，而不是为了炫技使用复杂泛型。
遇到第三方输入、JSON、表单和 API 响应时，要结合类型收窄或 schema 校验。

在真实项目中，可以把它当成一个判断框架：先确认输入、约束、失败场景和可观测性，再决定具体工具或写法。如果一个方案看起来很简单，要继续追问它在规模扩大、权限变化、异常恢复和团队协作下是否仍然成立。

实践检查清单

明确这个知识点在系统中的位置：是开发时约束、运行时能力、基础设施能力，还是协作流程。
写出一个最小可运行例子，并补一个失败例子；只会写 happy path 说明理解还不够稳。
记录常见误用：例如边界条件、权限假设、性能假设、同步/异步差异或环境差异。
把概念和项目经历关联起来：如果面试被追问，可以用自己的项目说明为什么这样选。
最后用一句话总结取舍：它牺牲了什么，换来了什么。

自测问题

这个主题解决的核心问题是什么？
如果不用当前方案，还有哪些替代方案？代价是什么？
最容易出错的边界条件在哪里？
如何在代码、测试或监控中验证它真的可靠？

项目化应用场景

可以把这类知识放到一个前后端共享类型的项目里理解：API 返回 JSON，前端先用 schema 做运行时校验，再把校验后的数据交给 TypeScript 类型系统。类型可以帮助编辑器提示和编译期检查，但不能保证网络返回一定正确。好的类型设计应该表达业务约束，例如角色、状态、权限、请求参数和响应结构，而不是所有地方都写成 string 或 any。

常见误区：

把 TypeScript 类型当成运行时校验。
为了省事使用 any，导致错误延后到线上。
泛型过度复杂，让调用者难以理解。

目录