不同的用戶使用 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。

更多Jerry的原創文章，盡在：“汪子熙”:

總結

以上是生活随笔為你收集整理的TypeScript strictness - 严格语法检查的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。