下面重點(diǎn)來了 - 凡是有泛型形參的地方，我們都可以通過 extends來表達(dá)類型約束。這里的類型約束展開說就是，泛型形參在實(shí)例化時(shí)傳進(jìn)來的類型實(shí)參必須要滿足我們所聲明的類型約束。到這里，問題就來了，我們?cè)撛鯓觼砝斫膺@里的「滿足」呢？在深究此問題之前，我們來看看類型約束的語法：

`泛型形參` extends `某個(gè)類型`

為了引出上面所說「滿足」的理解難題，我們不妨先看看下面的示例的代碼：

示例 2-1

// case 1
type UselessType = T;
type Test1 = UselessType // 這里會(huì)報(bào)錯(cuò)嗎？
type Test1_1 = UselessType // 這里會(huì)報(bào)錯(cuò)嗎？
// case 2
type UselessType2 = T;
type Test2 = UselessType2<{a:1, b:2, c:3}> // 這里會(huì)報(bào)錯(cuò)嗎？
type Test2_1 = UselessType2<{a:1}> // 這里會(huì)報(bào)錯(cuò)嗎？
type Test2_2 = UselessType2<{[key:string]: any}> // 這里會(huì)報(bào)錯(cuò)嗎？
type Test2_3 = {a:1, b:2} extends  {[key:string]: any} ? true : false
// case 3
class BaseClass {
    name!: string
}
class SubClass extends  BaseClass{
    sayHello!: (name: string)=> void
}
class SubClass2 extends  SubClass{
    logName!: ()=> void
}
type UselessType3 = T;
type Test3 = UselessType3<{name: "鯊叔"}> // 這里會(huì)報(bào)錯(cuò)嗎？
type Test3_1 = UselessType3 // 這里會(huì)報(bào)錯(cuò)嗎？
type Test3_2 = UselessType3 // 這里會(huì)報(bào)錯(cuò)嗎？

不知道讀者朋友們?cè)跊]有把上述代碼拷貝到 typeScript 的 playground 里面去驗(yàn)證之前你是否能全部猜中。如果能，證明你對(duì) extends在類型約束的語義上下文中的行為表現(xiàn)已經(jīng)掌握的很清楚了。如果不能，請(qǐng)?jiān)试S我為你娓娓道來。

相信有部分讀者了解過 typeScript 的類型系統(tǒng)的設(shè)計(jì)策略。由于 js 是一門動(dòng)態(tài)弱類型的腳本語言，再加上需要考慮 typeScript 與 js 的互操性和兼容性。所以， typeScript 類型系統(tǒng)被設(shè)計(jì)為一個(gè)「structural typing」系統(tǒng)（結(jié)構(gòu)化類型系統(tǒng)）。所謂的結(jié)構(gòu)化類型系統(tǒng)的一個(gè)顯著的特點(diǎn)就是 - 具有某個(gè)類型 A 的值是否能夠賦值給另外一個(gè)類型 B 的值的依據(jù)是，類型 A 的類型結(jié)構(gòu)是否跟類型 B 的類型結(jié)構(gòu)是否兼容。而類型之間是否兼容看重的類型的結(jié)構(gòu)而不是類型的名字。再說白一點(diǎn)，就是 B 類型有的屬性和方法，你 A 類型也必須有。到這里，就很容易引出一個(gè)廣為大眾接受的，用于理解類型「可賦值性」行為的心智模型，即：

以下是 示例 2-1的運(yùn)行結(jié)果：

實(shí)際上，上面的那個(gè)心智模型是無法匹配到以上示例在 typeScript@4.9.4 上的運(yùn)行結(jié)果。以上面這個(gè)心智模型（子集類型能賦值給父集類型，反之則不然）來看示例的運(yùn)行結(jié)果，我們會(huì)有下面的直覺認(rèn)知偏差：

經(jīng)過反復(fù)驗(yàn)證和查閱資料，正確的認(rèn)知如下：

基于上面的正確認(rèn)知，我們不妨把我們的心智模型修正一下：

注：

1）A -> B表示「A 是 B 的父類型，B 是 A 的子類型」；

2）strictNullChecks 編譯標(biāo)志位打開后，undefined,void和null就不會(huì)成為 typeScript 類型系統(tǒng)的一層，因?yàn)樗鼈兪遣荒苜x值給其他類型的。

關(guān)于上面這張圖，有幾點(diǎn)可以單獨(dú)拿出來強(qiáng)調(diào)一下：

現(xiàn)在我們用這個(gè)新的心智模型去理解一下 示例 2-1報(bào)錯(cuò)的地方：

到這里，我們算是剖析完畢。下面總結(jié)一下。

extends 與條件類型

眾所周知，ts 中的條件類型就是 js 世界里面的「三元表達(dá)式」。只不過，相比值世界里面的三元表達(dá)式最終被計(jì)算出一個(gè)「值」，ts 的三元表達(dá)式最終計(jì)算出的是「類型」。下面，我們先來復(fù)習(xí)一下它的語法：

AType extends BType ?  CType :  DType

在這里，extends關(guān)鍵字出現(xiàn)在三元表達(dá)的第一個(gè)子句中。按照我們對(duì) js 三元表達(dá)式的理解，我們對(duì) typeScript 的三元表達(dá)式的理解應(yīng)該是相似的：如果 AType extends BType為邏輯真值，那么整個(gè)表達(dá)式就返回 CType,否則的話就返回DType。作為過來人，只能說，大部分情況是這樣的，在幾個(gè)邊緣 case 里面，ts 的表現(xiàn)讓你大跌眼鏡，后面會(huì)介紹。

跟 js 的三元表達(dá)式支持嵌套一樣，ts 的三元表達(dá)式也支持嵌套，即下面也是合法的語法：

AType extends BType ?  (CType extends DType ? EType : FType) : (GType extends HType ? IType : JType)

到這里，我們已經(jīng)看到了 typeScript 的類型編程世界的大門了。因?yàn)椋磉_(dá)式本質(zhì)就是條件-分支語句，而后者就是邏輯編輯世界的最基本的要素了。而在我們進(jìn)入 typeScript 的類型編程世界之前，我們首要搞清楚的是，AType extends BType何時(shí)是邏輯上的真值。

幸運(yùn)的是，我們可以復(fù)用「extends 與類型約束」上面所產(chǎn)出的心智模型。簡(jiǎn)而言之，如果 AType是 BType的子類型，那么代碼執(zhí)行就是進(jìn)入第一個(gè)條件分支語句，否則就會(huì)進(jìn)入第二個(gè)條件分支語句。

上面這句話再加上「ts 類型層級(jí)關(guān)系圖」，我們幾乎可以理解AType extends BType99% 的語義。還剩下 1% 就是那些違背正常人直覺的特性表現(xiàn)。下面我們重點(diǎn)說說這 1% 的特性表現(xiàn)。

extends 與 {}

我們開門見山地問吧：“請(qǐng)說出下面代碼的運(yùn)行結(jié)果?！?/p>

type Test = 1 extends {} ? true : false // 請(qǐng)問 `Test` 類型的值是什么？

如果你認(rèn)真地去領(lǐng)會(huì)上面給出的「ts 類型層級(jí)關(guān)系圖」，我相信你已經(jīng)知道答案了。如果你是基于「鴨子辯型」的直觀理解去判斷，那么我相信你的答案是false。但是我的遺憾地告訴你，在 typeScript@4.9.4中，答案是true。這明顯是違背人類直覺的。于是乎，你會(huì)有這么一個(gè)疑問：“字面量類型 1跟 {}類型似乎牛馬不相及，既不形似，也不神似，它怎么可能是是「字面量空對(duì)象」的子類型呢？”

好吧，就像我們?cè)谏弦还?jié)提過的，{}在 typeScript 中，不應(yīng)該被理解為字面量空對(duì)象。它是一個(gè)特殊存在。它是一切有值類型的基類。ts 對(duì)它這么定位，似乎也合理。因?yàn)楹魬?yīng)了一個(gè)事實(shí) - 在 js 中，一切都是對(duì)象 （字面量 1在 js 引擎內(nèi)部也是會(huì)被包成一個(gè)對(duì)象 - Number()的實(shí)例）。

現(xiàn)在，你不妨拿別的各種類型去測(cè)試一下它跟 {}的關(guān)系，看看結(jié)果是不是跟我說的一樣。最后，有一個(gè)注意點(diǎn)值的強(qiáng)調(diào)一下。假如我們忽略無處不在，似乎是百變星君的 any，{}的父類型只有一個(gè) - unknown。不信，我們可以試一試：

type Test = unknown extends {} ? true : false // `Test` 類型的值是 `false`

Test2類型的值是 false，從而證明了unknown是{}的父類型。

extends 與 any

也許你會(huì)覺得，extends與 any有什么好講得嘛。你上面不是說了「any」既是所有類型的子類型，又是所有類型的父類型。所以，以下示例代碼得到的類型一定是true:

type Test = any extends number ? true : false

額......在 typeScript@4.9.4 中, 結(jié)果似乎不是這樣的 - 上面示例代碼的運(yùn)行結(jié)果是boolean。這到底是怎么回事呢？這是因?yàn)?，?typeScript 的條件類型中，當(dāng)any出現(xiàn)在 extends前面的時(shí)候，它是被視為一個(gè)聯(lián)合里類型。這個(gè)聯(lián)合類型有兩個(gè)成員，一個(gè)是extends后面的類型，一個(gè)非extends后面的類型。還是用上面的示例舉例子：

type Test = any extends number ? true : false
// 其實(shí)等同于
type Test = (number | non-number) extends number ? true : false
// 根據(jù)聯(lián)合類型的分配率，展開得到
type Test = (number extends number ? true : false) | (non-number extends number ？ true : false)
          = true | false
          = boolean
// 不相信我？我們?cè)賮碓囈粋€(gè)例子：
type Test2 = any extends number ? 1 : 2
// 其實(shí)等同于
type Test2 = (number | non-number) extends number ? 1 : 2
// 根據(jù)聯(lián)合類型的分配率，展開得到
type Test = (number extends number ? 1 : 2) | (non-number extends number ？ 1 : 2)
          = 1 | 2

也許你會(huì)問，如果把 any放在后面呢？比如：

type Test = number extends any ? true : false

這種情況我們可以依據(jù) 「任意類型都是any的子類型」得到最終的結(jié)果是true。

關(guān)于 extends 與 any 的運(yùn)算結(jié)果，總結(jié)一下，總共有兩種情況：

extends 與 never

在 typeScript 的三元表達(dá)式中，當(dāng) never遇見 extends,結(jié)果就變得很有意思了?？梢該Q個(gè)角度說，是很奇怪。假設(shè)，我現(xiàn)在要你實(shí)現(xiàn)一個(gè) typeScript utility 去判斷某個(gè)類型(不考慮any)是否是never的時(shí)候，你可能會(huì)不假思索地在想：因?yàn)?never是處在 typeScript 類型層級(jí)的最底層，也就是說，除了它自己，沒有任何類型是它的子類型。所以答案肯定是這樣：

type IsNever = T extends never ? true : false

然后，你信心滿滿地給泛型形參傳遞個(gè)never去測(cè)試，你發(fā)現(xiàn)結(jié)果是never，而不是true或者false:

type  Test = IsNever // Test 的值為 `never`, 而不是我們期待的  `true`

再然后，你不甘心，你寫下了下面的代碼去進(jìn)行再次測(cè)試：

type  Test = never extends never ? true ： false // Test 的值為 `true`, 符合我們的預(yù)期

你會(huì)發(fā)現(xiàn)，這次的結(jié)果卻是符合我們的預(yù)期的。此時(shí)，你腦海里面肯定有千萬匹草泥馬奔騰而過。是的，ts 類型系統(tǒng)中，某些行為就是那么的匪夷所思。

對(duì)于這種違背直覺的特性表現(xiàn)，當(dāng)前的解釋是：當(dāng) never充當(dāng)實(shí)參去實(shí)例化泛型形參的時(shí)候，它被看作沒有任何成員的聯(lián)合類型。當(dāng) tsc 對(duì)沒有成員的聯(lián)合類型執(zhí)行分配律時(shí)，tsc 認(rèn)為這么做沒有任何意義，所以就不執(zhí)行這段代碼，直接返回 never。

那正確的實(shí)現(xiàn)方式是什么??？是這個(gè)：

type IsNever = [T] extends [never] ? true : false

原理是什么?。看鹪唬骸竿ㄟ^放入 tuple 中，消除了聯(lián)合類型碰上 extends時(shí)所產(chǎn)生的分配律」。

extends 與 聯(lián)合類型

上面也提到了，在 typeScript 三元表達(dá)中，當(dāng) extends前面的類型是聯(lián)合類型的時(shí)候，ts 就會(huì)產(chǎn)生類似于「乘法分配律」行為表現(xiàn)。具體可以用下面的示例來表述：

type Test = (AType | BType) extends SomeType ? "yes" : "no"
          =  (AType extends SomeType ? "yes" : "no") | (BType extends SomeType ? "yes" : "no")

我們?cè)賮砜纯础赋朔ǚ峙渎伞梗?code>(a+b)*c = a*c + b*c。對(duì)比一下，我們就是知道，三元表達(dá)式中的 |就是乘法分配律中的 +, 三元表達(dá)式中的 extends就是乘法分配律中的 *。下面是表達(dá)這種類比的偽代碼：

type Test = (AType + BType) * （SomeType ? "yes" : "no"）
          =  AType * （SomeType ? "yes" : "no") + BType * （SomeType ? "yes" : "no")

另外，還有一個(gè)很重要的特性是，當(dāng)聯(lián)合類型的泛型形參的出現(xiàn)在三元表達(dá)式中的真值或者假值分支語句中，它指代的是正在遍歷的聯(lián)合類型的成員元素。在編程世界里面，利用聯(lián)合類型的這個(gè)特性，我們可以遍歷聯(lián)合類型的所有成員類型。比如，ts 內(nèi)置的 utility Exclude就是利用這種特性所實(shí)現(xiàn)的：

type  MyExclude= T extends U ？ never :  T; // 第二個(gè)條件分支語句中， T 指代的是正在遍歷的成員元素
type Test = MyExclude<"a"|"b"|"c", "a"> // "b"|"c"

在上面的實(shí)現(xiàn)中，在你將類型實(shí)參代入到三元表達(dá)式中，對(duì)于第二個(gè)條件分支的T記得要理解為"a"|"b"|"c"的各個(gè)成員元素，而不是理解為完整的聯(lián)合類型。

有時(shí)候，聯(lián)合類型的這種分配律不是我們想要的。那么，我們?cè)撛趺聪@種特性呢？其實(shí)上面在講「extends 與 never 」的時(shí)候也提到了。那就是，用方括號(hào)[]包住 extends前后的兩個(gè)類型參數(shù)。此時(shí)，兩個(gè)條件分支里面的聯(lián)合類型參數(shù)在實(shí)例化時(shí)候的值將會(huì)跟 extends子句里面的是一樣的。

// 具有分配律的寫法
type ToArray = Type extends any ? Type[] : never; //
type StrArrOrNumArr = ToArray; // 結(jié)果是：`string[] | number[]`
// 消除分配律的寫法
type ToArrayNonDist = [Type] extends [any] ? Type[] : never;
type StrArrOrNumArr2 = ToArray; // 結(jié)果是：`(string | number)[]`

也許你會(huì)覺得 string[] | number[]跟 (string | number)[]是一樣的，我只能說：“客官，要不您再仔細(xì)瞧瞧？”。

extends 判斷類型嚴(yán)格相等

在 typeScript 的類型編程世界里面，很多時(shí)候我們需要判斷兩個(gè)類型是否是一模一樣的，即這里所說的「嚴(yán)格相等」。如果讓你去實(shí)現(xiàn)這個(gè) utility 的話，你會(huì)怎么做呢？我相信，不少人會(huì)跟我一樣，不假思索地寫下了下面的答案：

type  IsEquals= T extends U ? U extends T ? true : false :  false

這個(gè)答案似乎是邏輯正確的。因?yàn)?，如果只有自己才可能既是自己的子類型也是自己的父類型。然后，我們用很多測(cè)試用例去測(cè)，似乎結(jié)果也都符合我們的預(yù)期。直到我們碰到下面的邊緣用例：

type  Test1= IsEquals // 期待結(jié)果：true，實(shí)際結(jié)果： never
type  Test2= IsEquals<1,any> // 期待結(jié)果：false，實(shí)際結(jié)果： boolean
type  Test3= IsEquals<{readonly a: 1},{a:1}> // 期待結(jié)果：false，實(shí)際結(jié)果： true

沒辦法， typeScript 的類型系統(tǒng)有太多的違背常識(shí)的設(shè)計(jì)與實(shí)現(xiàn)了。如果還是沿用上面的思路，即使你把上面的特定用例修復(fù)好了，但是說不定還有其他的邊緣用例躲在某個(gè)陰暗的角度等著你。所以，對(duì)于「如何判斷兩個(gè) typeScript 類型是嚴(yán)格相等」的這個(gè)問題上，目前社區(qū)里面從 typeScript 實(shí)現(xiàn)源碼角度上給出了一個(gè)終極答案：

type IsEquals =
      (() => (T extends  X ? 1 : 2)) extends
      (() => (T extends  Y ? 1 : 2))
      ? true
      : false;

目前我還沒理解這個(gè)終極答案為什么是行之有效的，但是從測(cè)試結(jié)果來看，它確實(shí)是 work 的，并且被大家所公認(rèn)。所以，目前為止，對(duì)于這個(gè)實(shí)現(xiàn)只能是死記硬背了。

extends 與類型推導(dǎo)