TypeScript类型谓词中是否必须显式使用交叉类型？

本问题根据@jcalz的评论，从关联问题拆分而来。

首先看非泛型版本的断言函数代码：

declare const foo: Record<string, string>;
declare function bar(foo: Record<string, string>): asserts foo is {};
bar(foo);
foo;
// ^? 此处foo的类型被推断为{}

执行bar(foo)之后，foo的类型被直接收窄为{}，此时访问foo.prop会触发类型错误。

再看泛型版本的实现：

declare const foo: Record<string, string>;
declare function bar<T>(foo: T): asserts foo is T & {};
bar(foo);
foo;
// ^? 此处foo的类型仍为Record<string, string>

这个版本执行完bar(foo)后，foo的类型没有发生收窄，仍然保持Record<string, string>，可以正常访问foo.prop属性。

按照常规类型计算规则，Record<string, string> & {}的结果本应等价于{}，但两种写法仅因为类型谓词是否包含泛型交叉结构，就出现了完全不同的收窄结果。

这个差异是TypeScript的预期设计，并非bug，核心逻辑如下：

• 断言函数执行类型收窄时，只要谓词中包含未实例化的泛型参数，TypeScript就不会主动对交叉类型做提前化简。编译器会刻意保留T & {}这类结构，不会直接将其计算为{}。泛型参数T本身是可变的，后续类型推导、类型检查环节还需要用到T的原始约束信息，如果提前把交叉结果化简为{}，原T携带的所有类型信息会完全丢失。
• 非泛型版本的类型谓词是固定的具体类型{}，编译器收窄时会直接用这个具体类型替换变量的原有类型，因此会出现属性访问报错的现象。

实际上T & {}是TypeScript生态中沿用多年的常用写法，它的实际作用是过滤掉null和undefined类型，同时完整保留原类型T的所有属性结构。TypeScript团队刻意不对这类带泛型的交叉结构做自动化简，就是为了保留这个实用能力——如果编译器看到T & {}就自动合并为{}，这个非空断言的常规写法就彻底失效了。

TypeScript的类型化简一直遵循按需执行的策略：只有当类型完全由具体类型组成、不包含任何泛型参数时，编译器才会主动计算交叉、联合类型的最终归一化结果；只要类型中包含泛型参数，编译器就会优先保留类型的原始书写结构，避免提前化简丢失关键类型信息，导致后续类型推导出错。

内容的提问来源于stack exchange，提问作者graphemecluster