Foundations Refresher: Core TypeScript Type System for Intermediate Developers

如果你已经在生产环境中使用TypeScript超过6个月，大概率已经写过不下百次类型注解，处理过几十次类型报错，甚至能熟练使用`interface`定义对象类型、用联合类型处理多态场景。但当你试图阅读开源库的类型定义、理解React源码的类型写法、或是解决复杂的类型推断问题时，却常常卡壳：为什么这里的类型报错明明看起来是合理的？为什么这个泛型函数的返回值和我预期的不一样？这些卡壳的本质，往往不是高级类型模式太难，而是你对TypeScript核心类型系统的几个关键节点存在认知盲区——这些盲区在简单场景下不会暴露，但一到复杂类型推导的场景就会成为拦路虎。

根据2023年TypeScript官方开发者调查报告，68%的从业者认为“理解高级类型系统”是掌握TypeScript的最大障碍，其中72%的障碍直接来源于基础概念的漏洞：比如分不清`any`和`unknown`的适用场景、不会用可辨识联合处理多态逻辑、不知道`interface`和`type`的核心差异、泛型只会写最基础的`<T>`语法却不会用约束限制类型范围。本章会针对性补全这些知识漏洞，不仅会回顾你熟悉的基础语法，更会深入讲解这些语法背后的设计逻辑、常见踩坑点和实际开发中的最佳实践，为后续学习高级泛型、条件类型和映射类型打下扎实的基础。

---

Beyond the Basics: Deep Dive into Primitive and Special Types

大多数中级开发者对`string`、`number`、`boolean`、`null`、`undefined`、`symbol`、`bigint`这7种原始类型已经耳熟能详，也能熟练用`object`、`array`、`tuple`定义复杂数据结构，但往往对TypeScript中几个特殊的“底层类型”认知模糊，而这些类型恰恰是理解高级类型模式的核心。

`any` vs `unknown` vs `never`: 特殊类型的本质差异

这三个类型是TypeScript类型系统中最容易被混淆的概念，很多开发者会把它们混用，导致类型安全完全失效。

`any`: 类型系统的“后门”

`any`是TypeScript中最灵活的类型，它允许你对变量进行任意操作，完全绕过类型检查： ```typescript function parseValue(val: any): string { // 不会报错，即使val是number、boolean等其他类型 return val.toUpperCase(); }

parseValue(123); // 运行时直接报错：number does not have method toUpperCase parseValue(true); // 运行时同样报错 ``` `any`的核心特性是它是所有类型的父类型，也是所有类型的子类型：你可以把任何值赋值给`any`类型的变量，也可以把`any`类型的变量赋值给任何其他类型的变量。这种灵活性在迁移老JS代码、处理动态数据时有一定价值，但在新代码中使用`any`等于直接放弃了TypeScript的类型安全能力，相当于写了一个带语法高亮的JavaScript文件。

`unknown`: 类型安全的`any`

`unknown`是TypeScript 3.0引入的类型，被称为“类型安全的`any`”：它同样可以接收任何类型的值，但在使用之前必须进行类型缩小或类型断言，否则会触发编译错误： ```typescript function parseValue(val: unknown): string { // 直接调用toUpperCase会报错：Object is of type 'unknown' // return val.toUpperCase();

// 必须通过类型检查缩小范围后才能使用 if (typeof val === "string") { return val.toUpperCase(); // 这里val已经被收窄为string类型，合法 } if (typeof val === "number") { return val.toString().toUpperCase(); } throw new Error("Unsupported value type"); }

parseValue("hello"); // 正常返回"HELLO" parseValue(123); // 正常返回"123" parseValue(true); // 运行时抛出错误，符合预期 ``` `unknown`的核心设计逻辑是：你明确告诉TypeScript“我不知道这个值的类型，但我会在使用前做检查”，既保留了处理动态数据的能力，又不会破坏类型安全。在实际开发中，处理API返回数据、用户输入等不确定类型的场景，应该优先使用`unknown`而不是`any`。

::: tip 电子版侧边栏：`any`的适用场景 `any`并非完全不能用：在迁移大型遗留JavaScript项目到TypeScript的过程中，临时用`any`标记暂时无法确定类型的动态模块，再逐步替换为具体类型，是业界通用的渐进式迁移策略。但任何新写的业务代码都不应该出现`any`。 :::

`never`: 底部类型的核心作用

`never`是TypeScript中的底部类型，代表永远不可能存在的值的类型。它是所有类型的子类型，但没有值是`never`类型的（除了抛出异常的函数、死循环函数等永远不会有返回值的场景）： ```typescript // 抛出异常的函数返回never function throwError(msg: string): never { throw new Error(msg); }

// 死循环函数返回never function infiniteLoop(): never { while (true) {} }

// never是所有类型的子类型，可以赋值给任何类型 let str: string = throwError("test"); let num: number = infiniteLoop(); ``` `never`最实用的场景是可辨识联合的穷尽性检查（exhaustive check）：当你处理一个联合类型的所有情况后，可以用`never`确保没有遗漏任何分支： ```typescript type Status = "success" | "error" | "pending";

function handleStatus(status: Status): void { switch (status) { case "success": console.log("操作成功"); break; case "error": console.log("操作失败"); break; // 如果漏掉了"pending"分支，下面的代码会报错 default: // 把status赋值给never类型的变量，如果还有未处理的分支，这里会触发编译错误 const _: never = status; throw new Error(`Unknown status: ${status}`); } } ``` 这个技巧在后面学习条件类型和映射类型时会频繁用到，是保证类型安全的核心手段之一。

字面量类型：从值到类型的跃迁

很多中级开发者只知道`"success"`是一个字符串值，不知道它同时也是一个字面量类型：`"success"`不仅是一个字符串，还是一个只能取`"success"`这个值的类型。字面量类型是可辨识联合的核心基础： ```typescript // 定义两个字面量类型 type SuccessStatus = "success"; type ErrorStatus = "error";

// 联合类型，只能取这两个值之一 type ApiStatus = SuccessStatus | ErrorStatus;

let s1: ApiStatus = "success"; // 合法 let s2: ApiStatus = "error"; // 合法 let s3: ApiStatus = "pending"; // 报错：Type '"pending"' is not assignable to type 'ApiStatus' ``` 除了字符串字面量类型，还有数字字面量类型（比如`type Num = 1 | 2 | 3`）、布尔字面量类型（`type Bool = true | false`），它们在实际开发中广泛用于定义枚举值、状态码等固定取值的场景。

::: warning 纸书注意框：字面量类型的 widening 问题 当你把一个字面量值赋值给一个没有明确标注类型的变量时，TypeScript会自动把它 widen（拓宽）为对应的原始类型： ```typescript let s = "success"; // 变量s的类型是string，不是"success" const s = "success"; // 常量的类型是"success"，因为const的值不会被修改 ``` 如果你希望变量保持字面量类型，需要显式标注，或者使用`as const`断言： ```typescript let s: "success" = "success"; // 显式标注，类型是"success" const obj = { status: "success" } as const; // obj.status的类型是"success"，不是string ``` :::

---

Interface vs Type Alias: When to Use Which

`interface`和`type`是TypeScript中定义类型的两种核心语法，几乎所有中级开发者都同时使用过两者，但很少有人能清晰说出它们的核心差异和适用场景。很多人习惯性地全部用`interface`，或是全部用`type`，这都是不合理的。

核心差异对比

我们从几个维度对比两者的差异，先看下表：

| 特性 | Interface | Type Alias | |------|-----------|------------| | 声明合并 | ✅ 支持，同名的`interface`会自动合并属性 | ❌ 不支持，同名的`type`会触发重复标识符错误 | | 扩展其他类型 | ✅ 支持`extends`继承其他`interface`/`type` | ✅ 支持`&`交叉其他类型，或`extends`继承其他类型 | | 定义联合/交叉类型 | ❌ 不支持 | ✅ 支持定义联合`|`、交叉`&`、映射等复杂类型 | | 描述函数/元组/原始类型 | ❌ 只能描述对象结构 | ✅ 可以描述任意类型 | | 性能 | 编译时检查更快，适合大型项目 | 编译时检查稍慢，复杂类型下差异明显 |

1. 声明合并：`interface`的独有能力

`interface`支持声明合并，即多个同名的`interface`定义会自动合并为一个，这个特性是TypeScript为了兼容现有JavaScript库设计的：比如DOM API的类型定义、第三方库的类型扩展，都是通过声明合并实现的： ```typescript // 第三方库定义了全局的Window接口 interface Window { myLib: { version: string; }; }

// 你自己的代码可以扩展Window接口，添加自定义属性 interface Window { myApp: { env: "development" | "production"; user: { id: string; name: string } | null; }; }

// 最终Window接口会自动合并两个定义 declare const window: Window; console.log(window.myLib.version); // 合法 console.log(window.myApp.env); // 合法 ``` 如果你用`type`定义`Window`，第二次定义会直接触发编译错误，无法扩展。这也是为什么TypeScript官方推荐在定义需要被第三方扩展的公共类型时，优先使用`interface`。

2. 复杂类型定义：`type`的独有能力

`type`可以定义任意类型的别名，包括联合类型、交叉类型、元组类型、函数类型等，这是`interface`做不到的： ```typescript // 用type定义联合类型 type StringOrNumber = string | number;

// 用type定义函数类型 type Fn = (a: string, b: number) => boolean;

// 用type定义元组类型 type Tuple = [string, number, boolean];

// 用type定义映射类型 type Partial<T> = { [P in keyof T]?: T[P] };

// 以上所有用法都无法用interface实现 ```

3. 扩展能力对比

两者都支持扩展其他类型，但扩展的逻辑不同： ```typescript // interface extends interface：继承属性，可以新增属性 interface Animal { name: string; } interface Dog extends Animal { bark(): void; }

// interface extends type：继承type的所有属性 type Animal = { name: string; }; interface Dog extends Animal { bark(): void; }

// type extends type：继承type的所有属性 type Animal = { name: string; }; type Dog = Animal & { bark(): void; }; ``` 可以看到，`interface`的`extends`更符合面向对象的继承语义，而`type`的`&`交叉类型更灵活，可以组合任意类型。

适用场景最佳实践

根据上述差异，我们可以总结出明确的适用场景： 1. 定义需要被第三方扩展的公共对象类型（比如SDK的类型定义、全局变量类型）：优先用`interface`，利用声明合并的能力。 2. 定义联合类型、交叉类型、函数类型、元组类型等复杂类型：必须用`type`。 3. 定义不会被扩展的简单对象类型：两者都可以，根据团队规范选择即可，目前社区更倾向于用`type`，因为语法更统一、支持更复杂的类型操作。 4. 定义React组件的Props类型：两者都可以，但如果Props需要被高阶组件扩展，优先用`interface`。

::: tip 电子版侧边栏：性能差异的实际影响 在大型项目中，`interface`的编译检查速度会比`type`快10%~30%，尤其是在定义大量复杂交叉类型、条件类型的场景下，差异会更明显。如果你的项目有数千个类型定义，优先用`interface`定义公共对象类型可以显著提升编译速度。 :::

---

Union and Intersection Types: Beyond Simple Combinations

联合类型（`|`，表示“或”）和交叉类型（`&`，表示“且”）是TypeScript中处理多态数据的核心工具，但很多中级开发者只会用它们做简单的类型组合，不知道如何结合类型缩小、可辨识联合等特性处理复杂逻辑。

联合类型与类型缩小

联合类型的核心价值是表示一个值可以是多种类型之一，但直接使用联合类型的变量时，你只能访问所有类型共有的属性和方法： ```typescript type StringOrNumber = string | number;

function printLength(val: StringOrNumber) { // 报错：Property 'length' does not exist on type 'StringOrNumber' // console.log(val.length);

// 必须通过类型缩小，确定val的具体类型后才能访问对应属性 if (typeof val === "string") { console.log(val.length); // val被收窄为string，合法 } else { console.log(val.toString().length); // val被收窄为number，合法 } } ``` TypeScript提供了多种类型缩小的手段，除了最常用的`typeof`（用于缩小原始类型），还有：

• `in`操作符：用于检查对象是否包含某个属性，缩小对象联合类型
• `instanceof`操作符：用于检查对象是否是某个类的实例，缩小类类型
• 自定义类型保护函数：通过返回类型谓词（`arg is Type`）手动缩小类型范围

可辨识联合：联合类型的终极用法

可辨识联合（Discriminated Union）是联合类型最实用的模式，它通过给联合类型的每个成员添加一个公共的字面量属性（称为“可辨识属性”），来快速区分不同的类型成员： ```typescript // 定义API响应的两种状态，用status作为可辨识属性 type ApiResponse<T> = | { status: "success"; data: T; error: null } | { status: "error"; data: null; error: Error };

// 处理API响应的函数，通过switch判断status字段即可快速缩小类型 function handleResponse<T>(res: ApiResponse<T>) { switch (res.status) { case "success": // 这里TypeScript自动知道res是success分支的类型，data是T，error是n