写业务久了，很多人对 TypeScript 的认知停留在 "给变量标类型"。但翻开源码或库的类型声明，会看到另一层世界：一串看起来像代码、又像数学公式的写法，能根据输入 "算出" 新的类型。2026 年下半年，TypeScript 官方文档更新了条件类型与模板字面量类型的章节，5.7 版本也在类型收窄上做了补强。本文不堆代码，用大白话拆开这两套机制的运行逻辑。
一、条件类型：编译期的一台 "小计算器"
普通代码里的三元表达式是运行时算的，条件类型是编译期算的。它的读法可以理解成：如果 A 能放进 B 的盒子里，走左边；否则走右边。
第一个容易踩的坑是 "拆开再合并"。当传入的是一个联合类型（相当于 "或" 的关系）时，TypeScript 会把每一种可能性单独过一遍，再把结果并回来。这就像体检分科：一个集合里既有成年人又有儿童，体检中心不会一起测，而是分成两批、各用各的标准，最后汇总成一份报告。
你可能见过用方括号把类型包起来的写法 —— 那是手动告诉编译器 "别拆，当整体判断"。分布式展开是设计好的特性，不是 bug；理解了它的触发条件，就能解释为什么同一个写法换个入参结果就变了。
第二个关键点是 infer，可以理解成 "匹配时留一个洞"。当编译器拿一个类型去跟结构对齐时，infer 所在的位置就是洞，编译器会自动反推出洞里应该是什么类型。日常用的 ReturnType、Parameters 这些内置工具类型，底层全靠这个机制实现 —— 库作者写类型声明，本质上就是在反复使用 "留洞 — 对齐 — 反推" 这一招。
二、模板字面量类型：把字符串拼接搬进类型空间
模板字面量类型跟模板字符串长得一样，只是用在 "类型" 的位置。基础行为就是拼接：把前后两段文字拼成一个新的字符串类型。
真正有威力的地方在于，当拼接的中间位置是一个 "或" 关系时，TypeScript 会自动把每一种组合都生成出来。这就像点套餐：主食可选米饭或面条、荤菜可选鸡或鱼，系统会自动列出全部四种搭配。事件系统、键路径推导这类场景，就是靠这个能力批量生成组合。
再配合映射类型的键重映射，还能批量给对象的每个属性生成带前缀的新键。这些字符串操作工具类型的实现，并不是运行时算法，而是编译器内置的字符变换规则 —— 你在声明文件里看到的只是签名，真正的处理发生在类型检查器内部。
三、两者配合：类型空间里的 "路径解析"
把条件类型和模板字面量拼起来，就能在类型空间里做更复杂的判断和转换。一个典型场景是从字符串里 "抠" 出路径的第一段：编译器拿路径字符串去跟 "某段开头＋一个点" 的结构对齐，匹配上了就把点之前的部分取出来，否则整体返回。
配合递归，就能实现深路径类型 —— 这在表单库、国际化库里很常见：你写一个嵌套对象，编辑器能自动提示出每一层的合法路径，输错了直接报错。理解它的关键，是把它当成 "逐层剥洋葱"：每一层剥出一个键，剥完这一层继续剥下一层。
需要提醒的是性能边界：递归过深、组合过大，会让类型检查时间明显上升，编辑器开始卡顿。工程上的取舍是 —— 把复杂的类型体操封装在库的边界内，业务代码只消费推导结果，不要在业务层随手写无限递归。
四、给学习者的建议
与其背 "体操大全"，不如按这个顺序吃透机制：先理解 extends 在类型位置的两种含义（约束 vs 判断），再动手写三五个 "留洞反推" 的小例子，最后用模板字面量加映射类型做一个带前缀键的小工具。把编译器当成一个可以单步观察的求值器 —— 鼠标悬停在变量上，看类型一步步怎么变，比死记语法快得多。
本文为行业科普分享，仅代表作者个人理解，文中信息来自公开资料，可能存在时效性差异，请以官方信息为准，仅供参考。
