TypeScript是JavaScript的超集。这是最大的一个误解！TS并不能在没有任何的条件下，包含JS，你必须升级TS编译器来支持新的JS特性，所以，TS并不是JS的超集，而是以JS为编译目标的另一门语言。TypeScript的核心概念就是“类型”，对于很多初接触TS的同学，类型就是冒号后面的内容，然而，事实真的是这样吗？本文将从一个另类的角度，聊一聊TS里面的泛型、&、子类型、类型推导、类型空间等话题，从而为你展现一个可能从来没想过的TS类型概念。

类型声明文件.d.ts

一切先从.d.ts文件开始说起吧。在我们已经写好的js库中，可以通过.d.ts向外提供本库的类型声明，以方便类似vscode之类的编辑器可以智能提示和补全，以及在ts项目中正确推导本库的api用法。在.d.ts文件中，我们通过declare来对需要暴露的api进行声明。

declare是一个新的关键字，起码我们在以前只写js的生涯中，从来没有使用过。我们如下声明一个函数：

declare function plus(a: number, b: number): number;

在声明中，我们只提供了函数的类型描述（下文我们会用形状Shape来表达这一概念），而没有函数的具体内容。这就像接口（interface）一样，只有描述，没有实现。如果我们的库是以模块的形式提供给外部使用，那么，只需要在最前面加上export导出这个函数的描述：

export declare function plus(a: number, b: number): number;

这样，在这个库的外部，当我们通过import导入它时，ts就会把它当作一个ES模块，并从模块中提供暴露的plus接口给外部的这个项目使用。

在.d.ts文件中，我们不会存在任何js的具体实现。？真的吗？也不一定，有时候我们会独立声明一个enum，而此时，你需要给定具体的值，以方便在外部阅读。

export enum Colors {
  Red: 'red';
  Blue: 'blue';
  Yellow: 'yellow';
}

export declare function paint(color: Colors): void;

注意第一个export，倘若此处我们不导出enum，那么我们在外部只能通过硬编码的形式传入字符串的red/blue/yellow，但当我们导出之后，就可以在外部使用Colors.Red等：

import { Colors } from 'some-lib/index.d' // <- 把它当作一个普通的.ts导入
import { paint } from 'some-lib'

paint(Colors.Red)

.d.ts只是一个摘要文件，它不被作为真正的运行时代码进行编译，但同时，我们也可以把它作为一个.ts文件进行使用，使用时，通过declare声明的部分，不会被作为运行时进行编译。

当你读到这里的时候，我想，你应该对declare产生了兴趣，以及对带来这个新语法的新语言产生了兴趣。但是，不要着急，我们还有很多东西要聊。

&不是“交集”？

我们直观感受是，当看到&时，我们要得到一个交集。例如：

interface A {
  name: string;
  age: number;
}

interface B {
  name: string;
  weight: number;
}

我们直观感受是，A&B -> interface C { name: string }，然而，事实恰恰相反，A&B的结果是：

interface D {
  name: string;
  age: number;
  weight: number;
}

咦……这……不是并集吗？为了便于理解，你可以这样想：D既符合A也符合B，所以是A和B的“交叉”。但是，如果只能通过这种方式来记忆TS，那么，真的毫无意义，掌握不到TS的皮毛。

此extends非彼extends

TS中的extends和JS里面的extends形式相同概念不同。例如：

interface Animal {
  name: string;
}

interface Snake extends Animal {
  length: number;
}

Snake是在Animal的基础上增加了length字段。我们可以换一种写法：

type Snake = Animal & {
  length: number,
}

两者在语义上是有差别的，虽然结果上一致。太不可思议了，我看到了感觉上完全不同的两种操作，竟然得到了相同的结果？

extends在TS中，代表着从一个类型扩展出另外一个新类型，这个新类型是原来这个类型的子类型。同时，extends在TS中具有条件属性，它用于判断一个类型是否是另外一个类型的子类型：

type Some = A extends B ? C : D

在这一意义上，TS和JS中的extends具有完全不同的性质。JS中extends代表继承（inherit），而TS中extends就是它的字面意思“扩展”。

Subtyping子类型

子类型是一个庞大的话题，涉及到抽象概念、（推导）规则、协变、逆变等等，你可以阅读这篇文章深入了解，本文只会聊其中很小的一部分。子类型揭示了TS类型系统的核心实质，它是一个推导系统，推导即基于某些定理、公理、定律进行演算的过程（在TS中主要是基于内建的一些规则用于检查值的类型）。

TS的类型基于“集合”的概念。一个类型，代表一个集合，例如string类型代表的是所有字符串的集合。在检查过程中，如何决定一个值属于这个“集合”呢？它的依据在于这个值的“形状（Shape）”。怎么定义值的形状呢？它由两部分组成，一部分是基于JS的基础类型，得到该值的数据类型，另一部分是基于TS的另外一个核心Structural（结构化的），得到该值的结构。基于数据类型和结构这两个概念，TS获得值的形状，基于“推导”的运行方式，决定该值是否符合某个类型。

正是这样，那么下面两个类型，在TS里面，竟然是“相等”的：

class A {
  name: string;
}

class B {
  name: string;
}

这在Java或C#这样的语言中，完全不能被理解，它俩怎么可能相等？而在TS中，它们代表着形状为 { name: string } 的对象（JS中一切复合类型皆是对象）的集合。一个值，在TS中，它和集合的对应关系不是一对一的，它可以同时属于多个集合中，是一对多的关系。而同时，两个不同的集合，却可能表达相同的形状。如果你看它像鸭子，那么它就是鸭子。于是，A和B相等了，只是取了不同的名字而已，就像一个人在这个杂志上叫鲁迅，在另一个杂志上叫润土。

TS是怎么对待（treat）这些集合的呢？它基于一种推导的范式确定两个集合之间的关系。两个集合存在什么关系呢？只存在两种关系：一种是A是B的子类型，另一种是A不是B的子类型。（A和B可交换位置。）子类型，是TS对待类型集合的唯一方式。在TS中，所有类型的总和，都处在子类型体系中，这个子类型体系是一个树状网络，它的根是一个叫unknow的类型，而它的底是一个叫never的类型（never是所有类型的子类型，是树状的所有叶子）。

子类型用于表达类型与类型的二元关系，当一个值的类型属于某一类型时，它同时属于该类型的父类型。它的产生方式又有多种，一种是基于父类型扩展，也就是使用extends，一种是基于一种叫交叉（A & B）的操作得到，一种则是基于一种叫联合（A | B）的操作得到。曾经有这样一个预言，让一只猴子坐在一台电脑前敲击键盘，总有一天它能敲出莎士比亚的所有著作（猴子不懂艺术）。同样的道理，只要给定条件，你永远可以在TS的子类型体系中找到对应的类型，而这个过程基于“推导”完成。因此，实际上，子类型的产生方式只有一种而非三种或更多，这种方式就是基于某一类型（never除外）扩展出新类型。

字面量类型

基于“形状”我们确实可以做类型的断言，但是这套方法会有个例外：字面量类型。特别是基础类型的字面量类型，比如string, number等的字面量。字面量类型只有结构（structure）没有数据类型，这听上去有点反常识，且往下读。

type Str = 'hello' | 'world'
let a: Str = 'hello'

我们在用字面量类型时，常常并不是按照我们所想的那样工作，例如：

type Source = {
  name: string,
  ext: 'mp3' | 'mp4',
}
function play(source: Source): void {
  ...
}
const source = { 
  name: 'xxx',
  ext: 'mp3',
}
play(source) // <- error

此时却会抛出错误。这是因为当TS在断言时，是以形参source的形状进行推导，对实参source的形状进行断言。因此，接收到的参数在形状上是 { name: string, ext: string } 并不是Source的子类型，所以TS认为此处检查不通过。解决办法是在实参source.ext后面跟上as const，告诉编译器此处我强制'mp3'为常量，因此就符合Source的约束。

但这个问题不是由字面量本身引起的，我们看另外一个case：

type Ext = 'mp3' | 'mp4'

const mp3 = 'mp3'

function play(ext: Ext): void {}

play(mp3) // <- ok

字面量本身并不会带来问题，问题在于mut（可变）。假如我上面把const mp3改为let mp3，此时就会报错。在play接收source的时候，虽然此时source.ext的值为mp3，但是，并不代表source.ext的值永远为mp3，因为它是可变的。假如它是不可变的，那么就没有问题。

问题解决了，现在，让我们回到类型系统的讨论上来。

上文提到TS基于推导进行类型断言，推导就是寻找子类型二元关系，如果不存在父子类型关系，就断言失败，抛出错误。那么，'mp3' | 'mp4' 的子类型是谁呢？'mp3', 'mp4' 和 never，以及它自身。

现在，'mp3' & 'mp4'的子类型时谁呢？就是它的本身never。为什么它的本身是never呢？我们来看，'mp3'的子类型是什么？'mp3'和never。'mp4'的子类型呢？'mp4'和never。只有never满足'mp3'&'mp4'。

我们回过头来看文章前面提到的A&B的例子。

interface A {
  name: string;
} // -> { name: string }

interface A1 extends A {
  age: number;
} // -> { name: string, age: number }

interface A2 extends A {
  weight: number;
} // -> { name: string, weight: number }

interface B {
  sex: string;
} // -> ???

谁是A的子类型一目了然了吧。所有含有name:string的形状都是A的子类型，包括A本身，以及never。那么，谁是B的子类型呢？所有包含sex:string的形状都是B的子类型，包括B本身，以及never。

现在，我们知道了A&B本身是A&B的子类型，那么A&B是什么？是指“既是A的子类型，也是B的子类型”的类型，也就是A的子类型的集合与B的子类型的集合的交集。所以，A&B表达的是这样的“交集”，而实际产生的结果是形状的“并集”，这并不是矛盾的，而是推导结果。

纯类型编程

TS的类型系统几乎快要成为图灵完备的一门语言，你可以用它来写出一门新语言。我们要理解的是，纯类型编程和作为JS超集的TS编程的边界。我们几乎不会只写类型，而不写JS代码……等一下，真的不会吗？我们有的时候，会把项目中反复用到的一些类型，提取到公用的typings目录下进行管理，在其他地方引入这些类型。当我们脱离JS单纯写类型的时候，我们开始进入另外一个世界，这个世界叫类型空间。

我们写JS处于一个叫值空间的世界，面向运行时编程。而在类型空间，我们面向编译时编程。大多数情况下，两个空间是隔绝的（虽然在写代码的时候大部分情况下它们被写在一起），但偶尔也有例外，也就是字面量类型出现的时候，TS会在两个世界传送字面量（的结构而非值），以完成类型识别。所以严格讲，值，永远不会出现在类型空间。

在官方网站有这样一句话：别名只是别名。它的意思是，你并非在用type关键字定义一个类型，你只是给一个类型取了一个别名。无论你给一个类型取了多少个别名，它还是它自己，没有发生任何变化。

联合类型或交叉类型不具备存储类型的功能。例如type C = A & B，C并不能存储一个具体的类型，而是存储一个推导逻辑。原因很简单，因为C是无数个类型的集合。而在前面我们讲过，一个类型是一个集合，所以，C是无数个集合的集合。你不可能存储无数个类型。C参与断言的方式，是将具体的形状，参与推导过程。举个例子：有一条这样的规则：S-Arrow: 对于任何类型T₁,T₂,S₁,S₂ ,如果T₁<:S₁, 而且S₂<:T₂,那么S₁->S₂ <: T₁->T₂。

declare const foo: (x: unknown) => string; // S1->S2
const bar: (x: number) => unknown = foo; // T1->T2

在上面的这个例子中，TS可以根据S-Arrow规则，快速断言foo的类型是bar的类型的子类型，所以，将foo赋值给bar是完全ok的操作。类似这样的规则，是具有数学意义的公理、定理或定律，有的是前提条件，有的是推导结论，在TS的断言中，都可以直接使用。基于这些推导规则，TS并不需要确定一个别名的具体类型，而可以做到编译时实时且高效的推导和断言。

“类型”是TS世界的一等公民，是唯一的主角，TS类型编程无非是基于一个或多个类型，生成其他类型。但类型世界的运转规则和值世界的运转规则完全不同。值世界的新值由计算得到，计算规则有常见的运算、辅助运算规则、内存与数据结构、位运算等等。类型世界的新类型如上文所述，由父类型扩展而来，扩展规则有扩展、联合、交叉、推导、获取等。类型具有抽象性，TS没有命令指令，因此没有副作用，因此类型只能被创建无法被修改，因此TS是静态的系统。没有副作用并不代表无法实现编程，和值世界完全不同的运行规则，让TS可以基于推导完成复杂的编程，而我们常把这种需要动脑子找到推导路径的过程称为“类型体操”，例如，我们找出从A|B推导出A&B的路径是type UnionToIntersection<U> =
(U extends any ? (k: U)=>void : never) extends ((k: infer I)=>void) ? I : never。

除了借用JS的typeof, in等指令关键字外，TS的keyof, infer, as等指令，都不具备副作用。同时，在TS中，也支持三目运算，根据条件选择使用类型，例如 T extends Some ? T : Some. TS直接支持递归，可配合泛型用于替代循环语句。keyof和in配合可用于支持迭代遍历效果。泛型，则是通往类型编程的高速公路，是实现类型编程的核心条件。

我在之前的一篇博客文章中有聊过自己第一次接触泛型时，如何用已知的知识理解它。但那种理解仍然是套用知识，而非认知。简单讲，泛型是TS类型编程中的“函数”，用以根据已有类型，按照给定推导路径，生成新的类型，可以简称为“类型生成函数”。泛型参数是TS中最有趣最灵活最强大最麻烦的存在。我们来看一下一个解构的例子：

const { name } = { name: 'yj' } // javascript

我们尝试用TS类型编程来做类似的事情（出自）：

type NameType<T> = T extends { name: infer N } ? N : never;
type name = NameType<{ name: 'yj' }>; // name is 'yj'

NameType可以从给定的类型中解构出给定类型的name属性的类型'yj'。前文提到在类型空间没有值，但是此刻，我们却可以利用TS的类型编程能力，获得的是泛型参数类型的name属性类型（字面量）。

但是遗憾的是，TS没有输出指令，类型世界的结果也无法传递给值世界，所以，我们在类型世界的编程，最终无法产生效果。不过随着时间的推移，事情有了转机，TS官方提供了生成器接口，通过一些工厂方法，你可以修改TS的编译结果。而在这个过程中，我们可以尝试破坏TS的Erased特性，保留类型的某些信息，从而可以将类型世界的结果传送回值的世界，输出类型编程的结果。

结语

本文并没有展开typescript中关于类型的用法，本文从另外一个角度，探索typescript中“类型”的概念，其中很多表述可能并不准确甚至并不正确，但是，我努力抛开用法，从本源出发去思考typescript中最核心（甚至是唯一）的概念。我们在写TS代码的时候，或许也该意识到，我们在做一件在两个世界之间穿越的事情，听起来很魔幻。掌握TS中类型的规律，我们必须深入去思考子类型是什么，并且在子类型体系中，寻求我们的最短路径。

2021-06-27 5897 TypeScript