一、any
(1)TypeScript 中表示任意类型。
log(message?: any, ...optionalParams: any[]): void
(2)除了显式的标记一个变量或参数为 any,在某些情况下你的变量/参数也会被隐式地推导为 any。比如使用 let 声明一个变量但不提供初始值,以及不为函数参数提供类型标注。
// any
let foo;
// foo、bar 均为 any
function func(foo, bar){}
以上的函数声明在 tsconfig 中启用了 noImplicitAny 时会报错,你可以显式为这两个参数指定 any 类型,或者暂时关闭这一配置(不推荐)。
(3) any 类型的变量几乎无所不能,它可以在声明后再次接受任意类型的值,同时可以被赋值给任意其它类型的变量。
// 被标记为 any 类型的变量可以拥有任意类型的值
let anyVar: any = "linbudu";
anyVar = false;
anyVar = "linbudu";
anyVar = {
site: "juejin"
};
anyVar = () => { }
// 标记为具体类型的变量也可以接受任何 any 类型的值
const val1: string = anyVar;
const val2: number = anyVar;
const val3: () => {} = anyVar;
const val4: {} = anyVar;
(4)可以在 any 类型变量上任意地进行操作,包括赋值、访问、方法调用等等,此时可以认为类型推导与检查是被完全禁用的。
let anyVar: any = null;
anyVar.foo.bar.baz();
anyVar[0][1][2].prop1;
(5)any 类型的主要意义,其实就是为了表示一个无拘无束的“任意类型”,它能兼容所有类型,也能够被所有类型兼容。这一作用其实也意味着类型世界给你开了一个外挂,无论什么时候,你都可以使用 any 类型跳过类型检查。当然,运行时出了问题就需要你自己负责了。
(6)避免随意写any
- 如果是类型不兼容报错导致你使用 any,考虑用类型断言替代,我们下面就会开始介绍类型断言的作用。
- 如果是类型太复杂导致你不想全部声明而使用 any,考虑将这一处的类型去断言为你需要的最简类型。如你需要调用
foo.bar.baz()
,就可以先将 foo 断言为一个具有 bar 方法的类型。- 如果你是想表达一个未知类型,更合理的方式是使用 unknown。
二、unKnown
(1)unknown 类型的变量可以再次赋值为任意其它类型,但只能赋值给 any 与 unknown 类型的变量。
let unknownVar: unknown = "linbudu";
unknownVar = false;
unknownVar = "linbudu";
unknownVar = {
site: "juejin"
};
unknownVar = () => { }
const val1: string = unknownVar; // Error
const val2: number = unknownVar; // Error
const val3: () => {} = unknownVar; // Error
const val4: {} = unknownVar; // Error
const val5: any = unknownVar;
const val6: unknown = unknownVar;
(2) unknown 和 any 的一个主要差异体现在赋值给别的变量时,any 就像是 “我身化万千无处不在” ,所有类型都把它当自己人。而 unknown 就像是 “我虽然身化万千,但我坚信我在未来的某一刻会得到一个确定的类型” ,只有 any 和 unknown 自己把它当自己人。简单地说,any 放弃了所有的类型检查,而 unknown 并没有。这一点也体现在对 unknown 类型的变量进行属性访问时:
let unknownVar: unknown;
unknownVar.foo(); // 报错:对象类型为 unknown
(3) 要对 unknown 类型进行属性访问,需要进行类型断言,即“虽然这是一个未知的类型,但我跟你保证它在这里就是这个类型!”:
let unknownVar: unknown;
(unknownVar as { foo: () => {} }).foo();
(4)在类型未知的情况下,更推荐使用 unknown 标注。这相当于你使用额外的心智负担保证了类型在各处的结构,后续重构为具体类型时也可以获得最初始的类型信息,同时还保证了类型检查的存在。
三、虚无的never类型
(1) never 是一个“什么都没有”的类型,它甚至不包括空的类型,严格来说,never 类型不携带任何的类型信息,因此会在联合类型中被直接移除。
(2)void 和 never 的类型兼容性
declare let v1: never;
declare let v2: void;
v1 = v2; // X 类型 void 不能赋值给类型 never
v2 = v1;
(3)在编程语言的类型系统中,never 类型被称为 Bottom Type,是整个类型系统层级中最底层的类型。和 null、undefined 一样,它是所有类型的子类型,但只有 never 类型的变量能够赋值给另一个 never 类型变量。
(4)通常我们不会显式地声明一个 never 类型,它主要被类型检查所使用。但在某些情况下使用 never 确实是符合逻辑的,比如一个只负责抛出错误的函数:
function justThrow(): never {
throw new Error()
}
(5) 在类型流的分析中,一旦一个返回值类型为 never 的函数被调用,那么下方的代码都会被视为无效的代码(即无法执行到):
function justThrow(): never {
throw new Error()
}
function foo (input:number){
if(input > 1){
justThrow();
// 等同于 return 语句后的代码,即 Dead Code
const name = "linbudu";
}
}
(6)可以利用只有 never 类型能赋值给 never 类型这一点,来巧妙地分支处理检查
if (typeof strOrNumOrBool === "string") {
// 一定是字符串!
strOrNumOrBool.charAt(1);
} else if (typeof strOrNumOrBool === "number") {
strOrNumOrBool.toFixed();
} else if (typeof strOrNumOrBool === "boolean") {
strOrNumOrBool === true;
} else {
const _exhaustiveCheck: never = strOrNumOrBool;
throw new Error(`Unknown input type: ${_exhaustiveCheck}`);
}
假设某个粗心的同事新增了一个类型分支,strOrNumOrBool 变成了 strOrNumOrBoolOrFunc,却忘记新增对应的处理分支,此时在 else 代码块中就会出现将 Function 类型赋值给 never 类型变量的类型错误。这实际上就是利用了类型分析能力与 never 类型只能赋值给 never 类型这一点,来确保联合类型变量被妥善处理。
(7)前面我们提到了主动使用 never 类型的两种方式,而 never 其实还会在某些情况下不请自来。比如说,你可能遇到过这样的类型错误:
const arr = [];
arr.push("linbudu"); // 类型“string”的参数不能赋给类型“never”的参数。
此时这个未标明类型的数组被推导为了 never[] 类型,这种情况仅会在你启用了 strictNullChecks 配置,同时禁用了 noImplicitAny 配置时才会出现。解决的办法也很简单,为这个数组声明一个具体类型即可。
四、类型断言:警告编译器不准报错
(1)类型断言能够显式告知类型检查程序当前这个变量的类型,可以进行类型分析地修正、类型。它其实就是一个将变量的已有类型更改为新指定类型的操作,它的基本语法是 as NewType,你可以将 any / unknown 类型断言到一个具体的类型:
let unknownVar: unknown;
(unknownVar as { foo: () => {} }).foo();
(2)还可以 as 到 any 来为所欲为,跳过所有的类型检查:
const str: string = "linbudu";
(str as any).func().foo().prop;
(3)也可以在联合类型中断言一个具体的分支:
function foo(union: string | number) {
if ((union as string).includes("linbudu")) { }
if ((union as number).toFixed() === '599') { }
}
(4)但是类型断言的正确使用方式是,在 TypeScript 类型分析不正确或不符合预期时,将其断言为此处的正确类型:
interface IFoo {
name: string;
}
declare const obj: {
foo: IFoo
}
const {
foo = {} as IFoo
} = obj
这里从 {} 字面量类型断言为了 IFoo 类型,即为解构赋值默认值进行了预期的类型断言。当然,更严谨的方式应该是定义为 Partial<IFoo> 类型,即 IFoo 的属性均为可选的。
(5)需要注意的是,类型断言应当是在迫不得己的情况下使用的。虽然说我们可以用类型断言纠正不正确的类型分析,但类型分析在大部分场景下还是可以智能地满足我们需求的。
(6)类型断言还有一种用法是作为代码提示的辅助工具,比如对于以下这个稍微复杂的接口:
interface IStruct {
foo: string;
bar: {
barPropA: string;
barPropB: number;
barMethod: () => void;
baz: {
handler: () => Promise<void>;
};
};
}
假设你想要基于这个结构随便实现一个对象,你可能会使用类型标注:
const obj: IStruct = {};
这个时候等待你的是一堆类型报错,你必须规规矩矩地实现整个接口结构才可以。但如果使用类型断言,我们可以在保留类型提示的前提下,不那么完整地实现这个结构:
// 这个例子是不会报错的
const obj = <IStruct>{
bar: {
baz: {},
},
};
类型提示仍然存在:
在你错误地实现结构时仍然可以给到你报错信息:
五、双重断言
(1) 如果在使用类型断言时,原类型与断言类型之间差异过大,也就是指鹿为马太过离谱,离谱到了指鹿为霸王龙的程度,TypeScript 会给你一个类型报错:
const str: string = "linbudu";
// 从 X 类型 到 Y 类型的断言可能是错误的,blabla
(str as { handler: () => {} }).handler()
(2)此时它会提醒你先断言到 unknown 类型,再断言到预期类型,就像这样:
const str: string = "linbudu";
(str as unknown as { handler: () => {} }).handler();
// 使用尖括号断言
(<{ handler: () => {} }>(<unknown>str)).handler();
(3)这是因为你的断言类型和原类型的差异太大,需要先断言到一个通用的类,即 any / unknown。这一通用类型包含了所有可能的类型,因此断言到它和从它断言到另一个类型差异不大。
六、非空断言
(1)非空断言其实是类型断言的简化,它使用 ! 语法,即 obj!.func()!.prop 的形式标记前面的一个声明一定是非空的(实际上就是剔除了 null 和 undefined 类型),比如这个例子:
declare const foo: {
func?: () => ({
prop?: number | null;
})
};
foo.func().prop.toFixed();
(2)此时,func 在 foo 中不一定存在,prop 在 func 调用结果中不一定存在,且可能为 null,我们就会收获两个类型报错。如果不管三七二十一地坚持调用,想要解决掉类型报错就可以使用非空断言:
foo.func!().prop!.toFixed();
其应用位置类似于可选链:
foo.func?.().prop?.toFixed();
但不同的是,非空断言的运行时仍然会保持调用链,因此在运行时可能会报错。而可选链则会在某一个部分收到 undefined 或 null 时直接短路掉,不会再发生后面的调用
(3) 非空断言的常见场景还有 document.querySelector、Array.find 方法等:
const element = document.querySelector("#id")!;
const target = [1, 2, 3, 599].find(item => item === 599)!;
为什么说非空断言是类型断言的简写?因为上面的非空断言实际上等价于以下的类型断言操作:
((foo.func as () => ({
prop?: number;
}))().prop as number).toFixed();
七、类型层级初探
(1) any 与 unknown 属于 Top Type,表现在它们包含了所有可能的类型,而 never 属于 Bottom Type,表现在它是一个虚无的、不存在的类型。
(2)层级关系
- 最顶级的类型,any 与 unknown
- 特殊的 Object ,它也包含了所有的类型,但和 Top Type 比还是差了一层
- String、Boolean、Number 这些装箱类型
- 原始类型与对象类型
- 字面量类型,即更精确的原始类型与对象类型嘛,需要注意的是 null 和 undefined 并不是字面量类型的子类型
- 最底层的 never
(3)实际上类型断言的工作原理也和类型层级有关,在判断断言是否成立,即差异是否能接受时,实际上判断的即是这两个类型是否能够找到一个公共的父类型。比如 { } 和 { name: string } 其实可以认为拥有公共的父类型 {}(一个新的 {}!你可以理解为这是一个基类,参与断言的 { } 和 { name: string } 其实是它的派生类)。
(4)如果找不到具有意义的公共父类型呢?这个时候就需要请出 Top Type 了,如果我们把它先断言到 Top Type,那么就拥有了公共父类型 Top Type,再断言到具体的类型也是同理。你可以理解为先向上断言,再向下断言,比如前面的双重断言可以改写成这样:
const str: string = "linbudu";
(str as (string | { handler: () => {} }) as { handler: () => {} }).handler();