不同的用户使用 TypeScript 在类型检查器中寻找不同的东西。有些人正在寻找更宽松的选择加入体验，它可以帮助仅验证其程序的某些部分，并且仍然拥有不错的工具。这是 TypeScript 的默认体验，其中类型是可选的，推理采用最宽松的类型，并且不检查潜在的 null/undefined 值。就像 tsc 在面对错误时发出的信息一样，这些默认值被放置到位以避开您。如果您正在迁移现有的 JavaScript，这可能是理想的第一步。
相比之下，许多用户更喜欢让 TypeScript 尽可能多地立即验证，这就是该语言也提供严格设置的原因。这些严格性设置将静态类型检查从开关（无论您的代码是否被检查）转变为更接近于拨号的东西。你把这个拨盘调得越远，TypeScript 就会为你检查越多。这可能需要一些额外的工作，但总的来说，从长远来看，它是物有所值的，并且可以实现更彻底的检查和更准确的工具。如果可能，新的代码库应该始终打开这些严格性检查。
TypeScript 有几个可以打开或关闭的类型检查严格标志，除非另有说明，否则我们所有的示例都将在启用所有这些标志的情况下编写。 CLI 中的 --strict 标志或 tsconfig.json 中的 “strict”: true 同时切换它们，但我们可以单独选择退出它们。您应该知道的两个最大的问题是 noImplicitAny 和 strictNullChecks：
noImplicitAny
回想一下，在某些地方，TypeScript 不会尝试为我们推断任何类型，而是退回到最宽松的类型：any。 这并不是可能发生的最糟糕的事情——毕竟，无论如何，回到任何只是普通的 JavaScript 体验。
然而，使用 any 通常首先会破坏使用 TypeScript 的目的。 您的程序类型越多，您获得的验证和工具就越多，这意味着您在编写代码时会遇到更少的错误。 打开 noImplicitAny 标志将对类型被隐式推断为 any 的任何变量发出错误。
strictNullChecks
默认情况下，像 null 和 undefined 这样的值可以分配给任何其他类型。 这可以使编写一些代码更容易，但忘记处理 null 和 undefined 是世界上无数错误的原因——有些人认为这是一个十亿美元的错误！ strictNullChecks 标志使处理 null 和 undefined 更加明确，让我们不必担心是否忘记处理 null 和 undefined。
