[[415751]]

本文轉載自微信公眾號「三分鐘學前端」，作者 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

來源：https://github.com/Advanced-Frontend/Daily-Interview-Question