不同的用戶使用 TypeScript 在類型檢查器中尋找不同的東西。有些人正在尋找更寬松的選擇加入體驗，它可以幫助僅驗證其程序的某些部分，并且仍然擁有不錯的工具。這是 TypeScript 的默認(rèn)體驗，其中類型是可選的，推理采用最寬松的類型，并且不檢查潛在的 null/undefined 值。就像 tsc 在面對錯誤時發(fā)出的信息一樣，這些默認(rèn)值被放置到位以避開您。如果您正在遷移現(xiàn)有的 JavaScript，這可能是理想的第一步。

相比之下，許多用戶更喜歡讓 TypeScript 盡可能多地立即驗證，這就是該語言也提供嚴(yán)格設(shè)置的原因。這些嚴(yán)格性設(shè)置將靜態(tài)類型檢查從開關(guān)（無論您的代碼是否被檢查）轉(zhuǎn)變?yōu)楦咏趽芴柕臇|西。你把這個撥盤調(diào)得越遠(yuǎn)，TypeScript 就會為你檢查越多。這可能需要一些額外的工作，但總的來說，從長遠(yuǎn)來看，它是物有所值的，并且可以實現(xiàn)更徹底的檢查和更準(zhǔn)確的工具。如果可能，新的代碼庫應(yīng)該始終打開這些嚴(yán)格性檢查。

TypeScript 有幾個可以打開或關(guān)閉的類型檢查嚴(yán)格標(biāo)志，除非另有說明，否則我們所有的示例都將在啟用所有這些標(biāo)志的情況下編寫。 CLI 中的 --strict 標(biāo)志或 tsconfig.json 中的 “strict”: true 同時切換它們，但我們可以單獨(dú)選擇退出它們。您應(yīng)該知道的兩個最大的問題是 noImplicitAny 和 strictNullChecks：

noImplicitAny

回想一下，在某些地方，TypeScript 不會嘗試為我們推斷任何類型，而是退回到最寬松的類型：any。 這并不是可能發(fā)生的最糟糕的事情——畢竟，無論如何，回到任何只是普通的 JavaScript 體驗。

然而，使用 any 通常首先會破壞使用 TypeScript 的目的。 您的程序類型越多，您獲得的驗證和工具就越多，這意味著您在編寫代碼時會遇到更少的錯誤。 打開 noImplicitAny 標(biāo)志將對類型被隱式推斷為 any 的任何變量發(fā)出錯誤。

strictNullChecks

默認(rèn)情況下，像 null 和 undefined 這樣的值可以分配給任何其他類型。 這可以使編寫一些代碼更容易，但忘記處理 null 和 undefined 是世界上無數(shù)錯誤的原因——有些人認(rèn)為這是一個十億美元的錯誤！ strictNullChecks 標(biāo)志使處理 null 和 undefined 更加明確，讓我們不必?fù)?dān)心是否忘記處理 null 和 undefined。

更多Jerry的原創(chuàng)文章，盡在：“汪子熙”:

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。