TypeScript 中，关于 any 类型，你需要知道的一切

[sisterAn]

any

在 TypeScript 中，任何类型的值都可以赋值给 any ， any 也可以赋值给任意类型，因此，any 类型通常也被称为 top type

let notSure: any

// 可以被赋值任意类型
notSure = 'sisterAn!'
notSure = 512
notSure = { hello: () => 'Hello sisterAn!' }

// 它也兼容任何类型
let num: number = 12
notSure = num
num = notSure

any 类型用于描述一个我们根本不知道类型的变量，或者说可以是任意类型的变量，常用于用户的输入或第三方代码库（不确定用户输入值的类型，第三方代码库是如何工作的），当我们刚接触 TypeScript 时， 或把 JavaScript 迁移至 TypeScript 时，经常会使用它，毕竟一写 any ，什么报错都没了

但大量使用 any 类型并不好，any 类型会提供一个类型系统的「后门」，当使用 any 时，你基本上是在告诉 TypeScript 编译器不要进行任何的类型检查。没有强制的类型检查，这在项目开发过程中可能会带来一些问题。

any 的问题

1. 类型污染

any 类型的对象会导致后续的属性类型都会变成 any ：

let user: any = {
  sister: {
    name: 'sisterAn'
  }
};
let sister = user.sister // any
let url = sister.url // any

2. 使用不存在的属性或方法而不报错

const notSure: any = 'sisterAn'
notSure.hello() // no error

所以，建议能不用 any 别用 any ，尽量少的使用 any

使用 any 更简单的场景，如何停止使用？

1. 添加类型时，我必须编写大量代码，any 工作量较少

可能不是，如果编写的代码为 any 类型，我们可能需要添加防御性代码，以确保参数和变量具有正确的类型，以使程序能够按预期执行。any 甚至无法防范 null 或 undefined

2. 我已经通过必要的运行时检查以防御性的方式编写了代码，以确保没有错误

现在可能没有错误，但是除非你有很好的测试覆盖率，否则以后来修改代码的人不会相信他们不是在错误中重构；就好像编译器不会帮你，因为我们说过它不会帮你。如果我们显式地设置类型并更改系统中使用的API，编译器将提供它的指导。

3. 有些参数很难正确输入，但是 any 更容易

如果我们将一些很难确定类型的输入定义为 any 类型，那么我们在后期如果没有正确地输入，将会造成编写错误，比我们在 JavaScript 会编写更多的错误，既然我们已经强制使用了 TypeScript ，就应该去利用它的特性，强制检查不正确的类型

4. 我真的不知道参数是什么

没关系! 我们可以用 unknown ; 它允许我们确实分配任何类型。但在确定特定类型之前，我们将不允许使用这些值。

function getName() {
 return 'sisterAn'
}

let sisterAn: unknown = getName()
sisterAn.hello() //Object is of type 'unknown'

5. 类型增加了很多复杂性，有时 any 更简单

使用 any 可能允许我们在不考虑数据如何流入逻辑的情况下更简单的开发。但它将这个负担会转移到我们代码的后期维护人、重构人身上。他们将不得不在没有上下文和编译器帮助的情况下理解项目是如何运行的，

总结

所以，我们能不用 any 别用 any ：

• 它使编译器过时了，我们告诉编译器：我不需要你的帮助
• 我们放弃了在编写代码时记录代码的机会
• 我们的第一道防线被攻破了
• 在动态语言中，我们假设事物可以有 any 类型，我们采用的模式遵循这个假设。如果我们开始使用静态类型语言作为动态语言，那么我们就是在与范式作斗争
• 当我们继续对代码库进行更改时，没有什么可以指导/帮助我们。
• 自由越大，责任越大(编译器)。不要变成一个编译器，我们的目的是使用编译器。

参考

• TypeScript： 请停止使用 any