为了能够表示“任意类型”，TypeScript 中提供了一个内置类型 any ，来表示所谓的任意类型。此时我们就可以使用 any 作为参数的类型：

  1. log(message?: any, ...optionalParams: any[]): void

在这里，一个被标记为 any 类型的参数可以接受任意类型的值。除了 message 是 any 以外，optionalParams 作为一个 rest 参数，也使用 any[] 进行了标记，这就意味着你可以使用任意类型的任意数量类型来调用这个方法。除了显式的标记一个变量或参数为 any，在某些情况下你的变量/参数也会被隐式地推导为 any。比如使用 let 声明一个变量但不提供初始值，以及不为函数参数提供类型标注：

  1. // any
  2. let foo;
  4. // foo、bar 均为 any
  5. function func(foo, bar){}

以上的函数声明在 tsconfig 中启用了 noImplicitAny 时会报错，你可以显式为这两个参数指定 any 类型，或者暂时关闭这一配置（不推荐）。而 any 类型的变量几乎无所不能，它可以在声明后再次接受任意类型的值，同时可以被赋值给任意其它类型的变量：

  1. // 被标记为 any 类型的变量可以拥有任意类型的值
  2. let anyVar: any = "linbudu";
  4. anyVar = false;
  5. anyVar = "linbudu";
  6. anyVar = {
  7.   site: "juejin"
  8. };
  10. anyVar = () => { }
  12. // 标记为具体类型的变量也可以接受任何 any 类型的值
  13. const val1: string = anyVar;
  14. const val2: number = anyVar;
  15. const val3: () => {} = anyVar;
  16. const val4: {} = anyVar;

你可以在 any 类型变量上任意地进行操作，包括赋值、访问、方法调用等等，此时可以认为类型推导与检查是被完全禁用的：

  1. let anyVar: any = null;
  3. anyVar.foo.bar.baz();
  4. anyVar[0][1][2].prop1;

而 any 类型的主要意义，其实就是为了表示一个无拘无束的“任意类型”，它能兼容所有类型，也能够被所有类型兼容。这一作用其实也意味着类型世界给你开了一个外挂，无论什么时候，你都可以使用 any 类型跳过类型检查。当然，运行时出了问题就需要你自己负责了。
any 类型的万能性也导致我们经常滥用它，比如类型不兼容了就 any 一下，类型不想写了也 any 一下，不确定可能会是啥类型还是 any 一下。此时的 TypeScript 就变成了令人诟病的 AnyScript。为了避免这一情况，我们要记住以下使用小 tips ：

  • 如果是类型不兼容报错导致你使用 any，考虑用类型断言替代，我们下面就会开始介绍类型断言的作用。
  • 如果是类型太复杂导致你不想全部声明而使用 any，考虑将这一处的类型去断言为你需要的最简类型。如你需要调用 foo.bar.baz()，就可以先将 foo 断言为一个具有 bar 方法的类型。
  • 如果你是想表达一个未知类型，更合理的方式是使用 unknown。

unknown 类型和 any 类型有些类似，一个 unknown 类型的变量可以再次赋值为任意其它类型，但只能赋值给 any 与 unknown 类型的变量：

  1. let unknownVar: unknown = "linbudu";
  3. unknownVar = false;
  4. unknownVar = "linbudu";
  5. unknownVar = {
  6.   site: "juejin"
  7. };
  9. unknownVar = () => { }
  11. const val1: string = unknownVar; // Error
  12. const val2: number = unknownVar; // Error
  13. const val3: () => {} = unknownVar; // Error
  14. const val4: {} = unknownVar; // Error
  16. const val5: any = unknownVar;
  17. const val6: unknown = unknownVar;

unknown 和 any 的一个主要差异体现在赋值给别的变量时，any 就像是 “我身化万千无处不在” ，所有类型都把它当自己人。而 unknown 就像是 “我虽然身化万千，但我坚信我在未来的某一刻会得到一个确定的类型” ，只有 any 和 unknown 自己把它当自己人。简单地说，any 放弃了所有的类型检查，而 unknown 并没有。这一点也体现在对 unknown 类型的变量进行属性访问时：

  1. let unknownVar: unknown;
  3. unknownVar.foo(); // 报错：对象类型为 unknown

要对 unknown 类型进行属性访问，需要进行类型断言（别急，马上就讲类型断言！），即“虽然这是一个未知的类型，但我跟你保证它在这里就是这个类型！”：

  1. let unknownVar: unknown;
  3. (unknownVar as { foo: () => {} }).foo();

在类型未知的情况下，更推荐使用 unknown 标注。这相当于你使用额外的心智负担保证了类型在各处的结构，后续重构为具体类型时也可以获得最初始的类型信息，同时还保证了类型检查的存在。当然，unknown 用起来很麻烦，一堆类型断言写起来可不太好看。归根结底，到底用哪个完全取决于你自己，毕竟语言只是工具嘛。
如果说，any 与 unknown 是比原始类型、对象类型等更广泛的类型，也就是说它们更上层一些，就像 string 字符串类型比 ‘linbudu’ 字符串字面量更上层一些，即 any/unknown -> 原始类型、对象类型 -> 字面量类型。那么，是否存在比字面量类型更底层一些的类型？
这里的上层与底层，其实即意味着包含类型信息的多少。any 类型包括了任意的类型，字符串类型包括任意的字符串字面量类型，而字面量类型只表示一个精确的值类型。如要还要更底层，也就是再少一些类型信息，那就只能什么都没有了。
而内置类型 never 就是这么一个“什么都没有”的类型。此前我们已经了解了另一个“什么都没有”的类型，void。但相比于 void ，never 还要更加空白一些。

虚无的 never 类型

是不是有点不好理解？我们看一个联合类型的例子就能 get 到一些了。

  1. type UnionWithNever = "linbudu" | 599 | true | void | never;


将鼠标悬浮在类型别名之上，你会发现这里显示的类型是”linbudu” | 599 | true | void。never 类型被直接无视掉了，而 void 仍然存在。这是因为，void 作为类型表示一个空类型，就像没有返回值的函数使用 void 来作为返回值类型标注一样，void 类型就像 JavaScript 中的 null 一样代表“这里有类型，但是个空类型”。
而 never 才是一个“什么都没有”的类型，它甚至不包括空的类型，严格来说，never 类型不携带任何的类型信息，因此会在联合类型中被直接移除，比如我们看 void 和 never 的类型兼容性：

  1. declare let v1: never;
  2. declare let v2: void;
  4. // X 类型 void 不能赋值给类型 never
  5. v1 = v2;
  6. v2 = v1;

在编程语言的类型系统中，never 类型被称为 Bottom Type，是整个类型系统层级中最底层的类型。和 null、undefined 一样，它是所有类型的子类型，但只有 never 类型的变量能够赋值给另一个 never 类型变量。
通常我们不会显式地声明一个 never 类型，它主要被类型检查所使用。但在某些情况下使用 never 确实是符合逻辑的，比如一个只负责抛出错误的函数：

  1. function justThrow(): never {
  2.   throw new Error()
  3. }

在类型流的分析中，一旦一个返回值类型为 never 的函数被调用，那么下方的代码都会被视为无效的代码（即无法执行到）：

  1. function justThrow(): never {
  2.   throw new Error()
  3. }
  5. function foo (input:number){
  6.   if(input > 1){
  7.     justThrow();
  8.     // 等同于 return 语句后的代码，即 Dead Code
  9.     const name = "linbudu";
  10.   }
  11. }

我们也可以显式利用它来进行类型检查，即上面在联合类型中 never 类型神秘消失的原因。假设，我们需要对一个联合类型的每个类型分支进行不同处理：

  1. declare const strOrNumOrBool: string | number | boolean;
  3. if (typeof strOrNumOrBool === "string") {
  4.   console.log("str!");
  5. } else if (typeof strOrNumOrBool === "number") {
  6.   console.log("num!");
  7. } else if (typeof strOrNumOrBool === "boolean") {
  8.   console.log("bool!");
  9. } else {
  10.   throw new Error(`Unknown input type: ${strOrNumOrBool}`);
  11. }

如果我们希望这个变量的每一种类型都需要得到妥善处理，在最后可以抛出一个错误，但这是运行时才会生效的措施，是否能在类型检查时就分析出来？
实际上，由于 TypeScript 强大的类型分析能力，每经过一个 if 语句处理，strOrNumOrBool 的类型分支就会减少一个（因为已经被对应的 typeof 处理过）。而在最后的 else 代码块中，它的类型只剩下了 never 类型，即一个无法再细分、本质上并不存在的虚空类型。在这里，我们可以利用 never 类型变量仅能赋值给 never 类型变量的特性，来巧妙地分支处理检查：

  1. if (typeof strOrNumOrBool === "string") {
  2.     // 一定是字符串！
  3.   strOrNumOrBool.charAt(1);
  4. } else if (typeof strOrNumOrBool === "number") {
  5.   strOrNumOrBool.toFixed();
  6. } else if (typeof strOrNumOrBool === "boolean") {
  7.   strOrNumOrBool === true;
  8. } else {
  9.   const _exhaustiveCheck: never = strOrNumOrBool;
  10.   throw new Error(`Unknown input type: ${_exhaustiveCheck}`);
  11. }

假设某个粗心的同事新增了一个类型分支，strOrNumOrBool 变成了 strOrNumOrBoolOrFunc，却忘记新增对应的处理分支，此时在 else 代码块中就会出现将 Function 类型赋值给 never 类型变量的类型错误。这实际上就是利用了类型分析能力与 never 类型只能赋值给 never 类型这一点，来确保联合类型变量被妥善处理。
前面我们提到了主动使用 never 类型的两种方式，而 never 其实还会在某些情况下不请自来。比如说，你可能遇到过这样的类型错误：
const arr = []; arr.push(“linbudu”);// 类型“string”的参数不能赋给类型“never”的参数。
此时这个未标明类型的数组被推导为了 never[] 类型，这种情况仅会在你启用了 strictNullChecks 配置，同时禁用了 noImplicitAny 配置时才会出现。解决的办法也很简单，为这个数组声明一个具体类型即可。关于这两个配置的具体作用，我们会在后面有详细的介绍。
在这一部分，我们了解了 TypeScript 中 Top Type(any / unknown) 与 Bottom Type（never）它们的表现。在讲 any 的时候，我们在小 tips 中提到，可以使用类型断言来避免对 any 类型的滥用。那么接下来，我们就来学习类型断言这一概念。