TypeScript类型入门：基本类型与联合类型

可视化演示

展示TypeScript类型核心机制：基本类型声明、联合类型分支与类型守卫收窄，可视化编译期类型检查如何提升代码安全性。

类型系统入门

大楼的保安队长先给你看了一段监控：因为没有门禁，一位“价格”溜进了“姓名”通道，结果收银台把客人的名字打印成了数字。JavaScript 就像这座不设防的大楼——变量随时可以变成任何类型，灵活但危险。

TypeScript 的理念很简单：“数据进门之前，先验明正身。”它会静态地检查每一个变量、函数参数和返回值，在代码运行之前就把类型矛盾暴露出来。这不是运行时监控，而是编译期门禁：只要类型不合规，编译就直接亮红灯。

类型系统本质上是在描述“哪些值属于哪些集合”。这份集合关系可用公式表达：

类型系统不是限制你，而是像门禁一样保护你：它可以告诉你“这扇门只能让 number 进去”，省去运行时飞来飞去的排查。给整栋楼装上这个门禁系统，正是 TS 存在的意义。

基本类型解剖

门禁系统发了好几款通行卡，颜色不同、权限不同。最基础的是四张“原始卡”：蓝色员工卡 string 存文本，红色访客卡 number 存数字，绿色临时卡 boolean 存真/假，还有很少单独占位的 null 和 undefined 两张“无权限卡”。

除了原始卡，还有“钱包型”的 object 可以装多个身份信息，array 是一叠同类卡片，tuple 是“先姓名后年龄”的固定卡槽。更特殊的是两张“万能卡”：any 表示放弃检查，谁都能刷；unknown 则是一张“待验证卡”，必须经过检查才能确定身份。

这些类型可以看作一个卡片集合：

理解了这些卡片，你写 let age: number = 30 时，就像给变量发了一张红色访客卡——别人再也不能往里面塞 "三十" 这个蓝色字符串了。保安看到卡色，就知道该放你进哪扇门。

联合类型

现实里，一扇门往往不认单一卡种：“访客走 1 号闸机，员工走 2 号闸机，但临时工没有专属卡怎么办？”门禁系统想了个办法：发一张“跨区双功能卡”，上面写着 string | number，表示只要持有其中任意一种身份就能通行。

联合类型用竖线 | 把多个类型连接起来，让变量拥有“或”的关系。它特别适合表达“这个字段可能是数字 ID，也可能是字符串 ID”之类的真实场景。你还可以联合 null 模拟可空值，或者联合固定的字面量字符串，实现类似枚举的选项。

一个联合类型在数学上就是多个集合的并集：

联合类型给你提供了弹性，但门禁依然不会让你随便进——数据进入函数后，保安还得分清它到底是哪种身份，这就轮到类型守卫登场了。

类型推断

老保安有一种本领：看到你胸口的工牌颜色，不用你开口，他就能判断你的身份。TS 也这样——你写 let name = "Alice"，它自动推断出 name 的类型是 string，根本不需要你画蛇添足地写 : string。

推断规则很有讲究：let 声明的变量会推断为宽泛的基础类型，比如 let x = 1 推断为 number；而 const 声明因为不可变，会推断为更精确的字面量类型，比如 const c = "a" 推断为 "a"。函数的返回值、泛型参数，也能根据表达式自动推断。

推断的过程简洁而强大：

类型推断让门禁系统变得贴心：大部分常见情况不用你手动贴标签，保安看初值就知道你是谁。但要注意，当 TS 推不出准确类型时，它会“偷懒”成 any——这时候你最好主动补上类型，别让门禁形同虚设。

类型守卫

拿到联合类型的数据后，保安不能凭一张“双功能卡”就放行。他会先问：“你到底是员工还是访客？” 然后根据回答，把你引导到对应的闸机。这个“根据类型选择分支”的过程，就叫类型守卫。

TS 最常用的守卫工具是 typeof，它可以精确判断 string、number、boolean 等原始类型。instanceof 适合判断类实例，in 适合判断对象是否拥有某个属性。每做完一次判断，TS 就会在分支内“收窄”变量的类型，让它从 string | number 变成单一的 string 或 number。

收窄的逻辑就像条件判断的推理：

有了守卫，联合类型不再是“薛定谔的身份”，而是“过闸机后明确身份”。记住：收窄越细致，你的代码就越不容易把字符串当数字去乘、把数字当字符串去拼接。

工程配置与迁移

门禁系统再好，也得有制度支撑。tsconfig.json 就是整栋楼的“安保制度文件”，它决定了哪些门禁规则必须开启。其中最要紧的是 strict 模式——开启后，TS 会拒绝所有隐式的 any，并把 null 和 undefined 都纳入检查，让安全级别瞬间拉满。

对于已经运行多年的老 JS 项目，你不可能一夜之间给所有人都补办卡片。聪明做法是“渐进式迁移”：先开启 allowJs 让 TS 项目能混编 JS 文件，再用 checkJs 逐步启用检查，最后对最关键的模块优先收编。就像先给重要楼层装门禁，再慢慢推广到全楼。

严格模式可以理解为多条规则的汇总：

别把 strict 当成负担，它是门禁的“最高权限设置”。老项目迁移也一样，不要急着推倒重建——先把门禁装上，再逐步收紧，才能让团队在风平浪静中完成过渡。

AI 应用场景

Python 演示

def simulate_type_narrowing(value):    if isinstance(value, str):        return "string 通道: " + value.upper()    if isinstance(value, int):        return "number 通道: " + str(value * 2)    if value is None:        return "null 通道: 检查失败"    return "unknown: 需要更多守卫" def main():    samples = [42, "hello", None, 3.14]    for s in samples:        print(simulate_type_narrowing(s)) if __name__ == "__main__":    main()

1. def simulate_type_narrowing(value):模拟一个接受联合类型参数的处理函数，对应 TS 的 function process(value: string | number | null)。
2. if isinstance(value, str):等价于 if (typeof value === "string")，判断数据是否为字符串。
3. return "string 通道: " + value.upper()在 str 分支内安全调用字符串方法，对应 TS 收窄后的类型安全操作。
4. if isinstance(value, int):对应 typeof value === "number" 的守卫条件。
5. return "unknown: 需要更多守卫"对应 TS 中 unknown 类型：未经过守卫确认前，不能贸然使用。

常见误区

面试题