TypeScript类型系统入门

可视化演示

展示从JavaScript到TypeScript的渐进迁移路径，以及TS的六大类型核心概念：Basic（基本类型）、Union（联合）、Inter（交叉）、Type（别名）、Interf（接口）、Infer（推导）。

类型系统概览

老李吃了发错货的亏，回来后第一件事就是找老师傅商量。老师傅说：“以前仓库小，货在眼前，靠眼睛盯就够；现在每天上千件货，谁还记得住哪个箱子装的是什么？”JavaScript 项目也一样：变量类型完全自由，一个人写的时候没问题，团队协作、项目变大之后，age 到底是数字还是字符串，只有程序跑起来的瞬间才知道——这就是“动态类型”的隐患。

TypeScript 的解法，是给 JavaScript 加一套“静态类型检查”。所谓“类型”，就是“这个值是什么货”；静态，就是“发货前定下来并核验一遍”。于是有了 let age: number = 18 这样的写法：: number 就是给变量贴上“数字类”标签，检查站师傅在编译期逐一核对，标签与实物不符就直接拦下。

需要强调的是，这套检查并不改变程序的运行方式。TypeScript 编译器完成核验后，产出的仍然是纯 JavaScript，老仓库的货车、公路、送货流程一条不变。

装上了检查站，仓库还是那个仓库，货车路线、配送时效都没变，只是从此“错货”在出库门前就被拦下。理解了这个定位，后面所有类型知识，都只是检查站里一张张具体的“标签规则”。

基础类型

检查站上班的第一天，师傅们先要认识“货品类别”——也就是贴纸。老李的仓库一共有几种最常用的标签：文本类的 string，电器类的 number，开关类的 boolean，还有表示“空包裹”的 null 和 undefined，以及装着杂七杂八东西的 object 和 array。这就是 TypeScript 的基础类型。

写法上非常直观，声明变量时在冒号后写上类型即可：

数组和对象也有自己的形状：number[] 表示“一排数字”；[number, string] 这种元组表示“第一个位置必须装数字、第二个位置必须装文本”的固定顺序货包。对象则用花括号描述“箱子里必须有哪些隔层”。

基础标签就是检查站的地基。有了这些贴纸，师傅们才能谈“二选一”和“全都要”——也就是后面要认识的联合类型与交叉类型。

let name: string = "tom";let age: number = 18;let isOk: boolean = true;

联合类型

新仓库上线后，发现一张发货单可能是客户在手机上下的电子单，也可能是传真来的纸质单——检查站得认两种格式。这个“要么 A 要么 B”的通道，就是联合类型，写法是用竖线 |：

联合类型的核验规则是“二选一放行”：标签与实物匹配其中任何一类就算过关。但问题来了——既然可能是 A 也可能是 B，检查站想知道“这张单到底是哪种”，就得现场判断。在 TS 里这叫“类型收窄”：

实战中还常用“可辨识联合”：给每种货物加一个特殊字面量标签，比如 { kind: "order" } 与 { kind: "invoice" }，检查站靠 kind 一眼分流；而 string | null 这种“空值兜底”则时刻提醒你：这个值可能是空包裹，必须处理。

联合类型就像仓库的“多规格通道”：一车货可以走 A 门或走 B 门，但门卫只有确认你走的是哪扇门，才放行该门专属的卸货设备。

let id: string | number = "abc-123";id = 99; // 同样合法

if (typeof id === "string") {  id.toUpperCase(); // 现在确认是 string, 可以放心调用字符串方法}

交叉类型

有些高端客户对包装有硬性要求：“既要防水，又要防火”——两种规格必须同时满足，缺一样都拒收。这种“全都要”的组合规格，就是交叉类型，用 & 表示：

交叉类型会把两边的“属性条款”合并成一个更大的形状：防水层要有，防火层也要有，组合成一个“既防水又防火”的包装箱。检查站核验时，每一项要求都要核对。

它和联合类型是仓库里最容易被拿反的两张规则：A | B 是“二选一挑一个用”，A & B 是“合在一起全部都要”。还有一个极端情况：如果两个规格互相矛盾，比如 string & number——要一个“既是文本又是数字”的箱子，根本做不出来，结果就是空类型 never。

交叉类型就是检查站里的“组合规格单”：要求每一条都打勾，少一层防火材料，箱子就不合格，直接退回。

type A = { x: number };type B = { y: string };type C = A & B;        // C 的值必须同时有 x 和 y

类型别名

发货单的规格组合越来越多，每次都在货单上写“文本或数字，或由系统生成的编号”太啰嗦。老师傅出了个主意：给常用规格起个名字，以后货单上只写名字，检查站翻规格本就能核验。这就是类型别名，用 type 关键字：

要点是：类型别名不创造新类型，它只是“老李”和“李老板”的关系——同一个人的两种称呼。检查站看到 UserId 时，会翻到规格册对应页面，按 string | number 的实际内容去核验。

别名的灵活性很高：可以指代联合、交叉、元组、对象等任何类型组合，还支持泛型参数成为“可定制尺寸的通用包装箱”：type Wrap<T> = { value: T }; 其中 T 由使用时现场指定。

别名让检查站的标签册从“几十种基础贴纸”扩展出“上千种组合规格”。规格再复杂，只要名字起得清楚，仓库的规则就能一直保持可维护。

type UserId = string | number;type Point = { x: number; y: number }; let uid: UserId = 42;let p: Point = { x: 1, y: 2 };

接口 interface

老李发现，和供应商长期合作不能只靠口头约定，得签合同：每批货必须符合合同条款，条款写什么，到货就核验什么。TypeScript 的 interface 就是这份“对象形状合同”：

合同中冒号是“必备条款”：任何自称 User 的对象，必须有 name 且它是 string。age? 是“可选条款”：可以没有；如果有，则必须是 number。检查站收货时，只核对合同上列出的条款。

接口之间还能“继承”——在主合同后面补签补充协议：interface Admin extends User { permissions: string[] }。管理员用户除了普通用户的条款，还多一条权限数组。另一个特点是“声明合并”：同名的 interface 会自动拼成一份更大的合同，就像两份补充协议拼在一起生效。

至于和 type 的区别：描述对象形状时两者都能用，社区惯例是“对象优先用 interface，遇到联合、交叉、元组时用 type”。这个边界，我们到误区部分再展开。

接口就是检查站与供应商之间那本“合作规格书”。合同条款越清晰，到货核验越顺畅，双方扯皮越少——放在代码里，就是前后端联调时的心照不宣。

interface User {  name: string;  age?: number;}

类型推导

检查站的老师傅干了二十年，有个本事：瞟一眼箱子外形，就知道里面大概是什么货——根本不用等贴标签。TypeScript 也有这种“直觉”，叫类型推导：

推导的规则很朴素：从“初始值”反推变量类型，从“返回值表达式”反推函数返回类型，甚至能借助“上下文”判断——比如事件回调里的事件对象，TS 会根据你绑定的元素自动补全类型。这解释了为什么很多 TS 代码看起来“没写类型，但处处有类型”。

但老师的直觉也有边界：函数参数没有初始值，推导无从下手，只能靠显式标注；复杂嵌套的对象结构，推导结果可能不够精确，也需要标注。最佳实践是“能推导的少写，边界处写清楚”——把类型注解留给函数参数、返回值这类“检查站看不到线索”的位置。

类型推导不是“从此不用写类型”，而是“减少你不得不写的类型”。老师傅认得出的货不必贴标签，但碰上没见过的新式货物，还是要老老实实把规则写下来。

let age = 18;        // age 被推导为 numberlet name = "tom";    // name 被推导为 string

渐进式迁移

老李的仓库不可能一夜之间全部翻新。他的做法是：先挑一个新分拣区试点，装上检查站跑顺，再逐步铺到老分区，最后把整个仓库改造完成。JavaScript 迁移到 TypeScript 也是同样的节奏。

第一步，开通 allowJs，允许 .js 老文件和 .ts 新文件混在一个项目里，新代码开始用 TS 写，老代码原地不动。第二步，开启 checkJs，让编译器开始对 .js 文件也做检查，老文件的隐患逐渐浮出水面。第三步是 strict：从关闭的“宽松检查”逐步收紧到“全面严格”，让团队先适应再下猛药。第四步，给暂时没时间改的老代码标上 any——一张“临时通行证”，先放行再回头补标签，最终的目标是把 any 一个个换回精确类型。

迁移的优先级也有讲究：先给公共数据模型、工具函数补类型，收益最高；业务代码可以缓一缓。TypeScript 编译器会自己列出一份“哪里还缺类型”的检查清单，按着清单推进，就像按着检查站的拦截记录逐项整改。

老仓库改造完成那天，每一件出库货物都贴上了标签，每一张发货单都经过检查站。发货前的错误少了，投诉电话也少了——TypeScript 给工程带来的，正是这种“把问题拦在发货前”的踏实感。

AI 应用场景

Python 演示

import sysfrom typing import Any, Dict, List  class SimpleTypeChecker:    """一个迷你类型检查站: 模仿 TypeScript 在运行前核对变量类型。"""     def __init__(self) -> None:        self.type_env: Dict[str, type] = {}        self.errors: List[str] = []     def infer(self, value: Any) -> type:        """类型推导: 像老师傅那样根据值直接判断出类型。"""        return type(value)     def declare(self, name: str, value: Any) -> None:        """声明变量: 不写标签, 由初始值推导出类型。"""        self.type_env[name] = self.infer(value)        print(f"[OK] 声明 {name}: {self.infer(value).__name__}")     def assign(self, name: str, value: Any) -> None:        """赋值检查: 新值必须与已推导的类型一致, 否则拦截。"""        if name not in self.type_env:            self.errors.append("未知变量 " + name)            return        expect: type = self.type_env[name]        actual: type = self.infer(value)        if expect != actual:            self.errors.append(                f"[拦截] {name} 期望 {expect.__name__}, 实际 {actual.__name__}"            )        else:            print(f"[OK] {name} 更新为 {value!r}")     def report(self) -> None:        """输出检查站拦截清单。"""        if not self.errors:            print(">>> 全部通过, 放行!")            return        print(">>> 检查站拦截清单:")        for err in self.errors:            print(err)  if __name__ == "__main__":    checker = SimpleTypeChecker()    checker.declare("age", 18)    checker.declare("name", "tom")    checker.assign("age", 19)    checker.assign("name", "bob")    checker.assign("age", "十九")    checker.assign("age", None)    checker.report()

1. self.type_env: Dict[str, type] = {}一张“变量 → 类型”登记表，相当于检查站的台账，记录每个变量当前的类型。
2. def infer(self, value: Any) -> type:定义“老师傅直觉”：输入一个值，返回它的类型，对应 TS 的类型推导。
3. self.type_env[name] = self.infer(value)声明变量时自动推导类型并登记，对应 let age = 18 被推导为 number。
4. if expect != actual:新值与登记类型不一致时记入拦截清单，对应 TS 编译期的类型报错。
5. checker.assign("age", "十九")用字符串给 number 型变量赋值，被检查站拦截并记录错误。
6. checker.report()输出本次“编译期检查”的完整结果，对应 TS 编译器打印的错误列表。

常见误区

面试题