TypeScript 的条件类型在处理联合类型时具有分布式特性，但编译器并不会盲目地把每一个候选类型都拿去实例化所有的分支类型。所谓类型实例化的短路优化，是指当条件类型的检查对象在某种情况下被判定为不需要继续展开或某个分支明显不会命中时，类型系统会主动跳过对该分支的实例化过程。这种机制既缩短了编译时间，也改变了我们肉眼推演类型结果的方式。下面通过具体场景说明它的运作逻辑。
短路优化在分布式条件类型中的触发规则
当条件类型形如 T extends U ? X : Y 且 T 为联合类型时，TypeScript 会将其拆分为 (A extends U ? X : Y) | (B extends U ? X : Y) ... 这样的分布式结构。但如果联合成员中包含 never，根据规范 never 在联合类型中会被吸收掉，相当于不存在。此时编译器不会为 never 生成任何分支实例，这就是一种最直观的短路。类似的，若某个成员在 extends 判断中绝对为假，且 X 或 Y 中涉及重型类型计算，新版本编译器也会尽量避免无谓的展开。
我们可以通过一个简单例子观察这种现象。下面代码中，NeverDemo 的结果并不会出现由 never 衍生出的分支类型，而是直接收敛为 string 对应的分支结果。
type Distributed<T> = T extends string ? "str" : "other"; type NeverDemo = Distributed<string | never>; // NeverDemo 实际等价于 Distributed<string> 即 "str"
除了 never 的吸收，TypeScript 在处理嵌套条件类型时也会做一定的惰性求值。例如当外层条件已经确定为 false，内层条件类型根本不会被实例化。这种短路不仅发生在联合分布阶段，也发生在条件类型的递归展开阶段。理解这一点，可以避免我们误以为编译器会执行“所有路径全展开”的暴力计算。
短路优化对类型推导结果的实际影响
很多开发者在书写工具类型时，会假设条件类型的每个分支都被平等实例化，从而预测出一个更大的联合类型。但短路机制会改变最终联合的构成。以 Exclude 的实现为例，它本质是 T extends U ? never : T。当 T 中含有 never 时，never extends U 得到 never，而 never 分支又返回 never，最终 never 被联合吸收，用户看到的排除结果中完全不包含 never 的踪迹。
再看一个容易踩坑的例子：自定义一个条件类型，在 true 分支做复杂的映射，在 false 分支直接返回原类型。如果传入的联合里混有确定不满足 U 的成员，那么 true 分支的复杂映射根本不会对该成员执行。这能提升性能，但也意味着你不能依赖 true 分支的副作用式类型变换去处理那些本就不会进入该分支的成员。
type MapIfString<T> = T extends string
? { value: T; len: number }
: T;
type Input = string | number | never;
type Output = MapIfString<Input>;
// Output 为 { value: string; len: number } | number
// never 没有产生任何分支实例
从推导结果反推，我们可以发现短路优化让类型系统表现得像在“剪枝”。如果你在测试工具类型时打印中间类型，发现某些预期中的分支类型消失，大概率不是编译器出错，而是短路把不可能或无效的路径去掉了。因此在设计泛型 API 时，应当把 never 和确定假分支视为透明成员。
如何利用短路优化编写高效的类型工具
既然短路优化不可避免，我们完全可以顺势利用它来降低类型计算的复杂度。一种常见做法是把最容易判定为 false 的条件放在外层，这样当入参明显不匹配时，内层重型类型直接被跳过。例如先判断是否为基本类型，再决定是否进入深层递归映射，能显著减少大型联合下的编译耗时。
另一个实践是避免人为制造“假联合”。有些代码会写出 string | never | string 这类冗余形式，虽然逻辑上等价于 string，但会让读者误以为有额外分支。保持入参联合的整洁，不仅能让短路行为可预测，也方便后续维护。同时，在编写条件类型时，若 false 分支只是原样返回 T，可以放心地依赖短路来忽略 never，而不必专门写一行处理 never 的重载。
type TrimNever<T> = T extends never ? never : T; // 实际上 T 中的 never 会被联合吸收，该工具类型多数情况下等价于 T type Clean = TrimNever<string | never | boolean>; // Clean 为 string | boolean
最后需要注意，短路优化是编译器实现层面的行为，不同 TypeScript 版本之间可能存在细微差异。在升级编译器后，如果某些极度依赖类型展开数量的测试出现变化，可以优先检查是否触碰了 never 吸收或条件剪枝的边界。将工具类型设计得尽量符合官方推荐模式，就能在享受短路带来性能收益的同时，规避推导结果不符预期的风险。
TypeScript条件类型短路优化修改时间：2026-08-19 09:39:32