當(dāng)我們開發(fā) TypeScript 代碼時，很可能會遇到 any 關(guān)鍵字。我們看到的大多數(shù)用法都表明我們正在處理 TypeScript 中的基本類型。在文檔中我們可能會找到：

[[347960]]

什么是 any

因此 any 不是通配符，也不是基類型，它是明確地與第三方庫進(jìn)行交互。那它為什么經(jīng)常出現(xiàn)你呢?它對我們的系統(tǒng)有害嗎?我們應(yīng)該逃避它還是擁抱它?

any 類型是使用現(xiàn)有 JavaScript 的強(qiáng)大方法，可讓您在編譯期間逐漸選擇加入和選擇退出類型檢查。

TypeScript 文檔明確表達(dá)了當(dāng)我們使用any類型時，我們正在告訴編譯器：

[[347961]]

當(dāng)超過500名該語言的貢獻(xiàn)者提供幫助時，我們說 no thank you。這聽起來像是選擇退出類型檢查器，有了它，就不能輕易地放棄對類型系統(tǒng)的所有安全性和信心。我們應(yīng)該使用它來與無類型的第三方(或第一方) Javascript 代碼交互，或者當(dāng)我們只知道類型的一部分時。

但是等等我還有很多其他原因

(1) TypeScript 不會轉(zhuǎn)換為 Javascript 嗎?Javascript 不是動態(tài)的嗎?那我為什么要考慮我的類型呢?

是的!但是我們用 TypeScript 寫代碼，這是一種靜態(tài)類型語言。有人可能會說靜態(tài)類型語言不會比動態(tài)語言產(chǎn)生更少的 bug 。不過，在使用 any 之類的靜態(tài)類型語言中，這是兩種情況中最糟糕的。

(2) 有些參數(shù)很難正確輸入，但是 any 更容易

如果我們沒有正確地輸入，我們將會編寫錯誤，比我們在動態(tài)語言中會編寫更多的錯誤，因?yàn)槲覀儚?qiáng)制 TypeScript ，一種靜態(tài)類型語言，去檢查不正確的類型。

(3) 我真的不知道參數(shù)是什么

沒關(guān)系!我們可以用 unknown ; 它允許我們確實(shí)分配任何類型。但在確定特定類型之前，我們將不允許使用這些值。

type ParsedType = { 
  id: number 
} 
 
const parseApiResponse( 
  response: Record<string, unknown> 
): ParsedType => { 
  const convertedResponse = (response as ParsedType) 
 
  // without doing the type cast we would 
  // get a type error here 
  if(convertedResponse.id >= 0) { 
    return convertedResponse 
  } else { 
    throw Error.new("Invalid response" 
  } 
} 

(4) 添加類型時，我必須編寫大量代碼，any工作量較少

可能不是，如果編寫的代碼沒有類型，則我們可能需要添加防御性代碼，以確保參數(shù)和變量具有正確的類型，以使程序能夠按預(yù)期執(zhí)行。any 甚至無法防范 null 或 undefined 檢查我們的邏輯 。

// version 1 with `any` 
const fullName = (user: any) => { 
  if (user?.firstName && user?.lastName) { 
    return `${user.lastName}, ${user.firstName}` 
  } 
 
  return user?.firstName || "" 
} 
 
// version 1 without `any` 
 
interface User { 
  firstName: string 
  lastName?: string 
} 
 
const fullName = ({ firstName, lastName }: User) => { 
  if (lastName === undefined) { 
    return firstName 
  } 
 
  return `${lastName}, ${firstName}`; 
} 

(5) 類型增加了很多復(fù)雜性，有時any更簡單

使用 any 可能允許我們在不考慮數(shù)據(jù)如何流入邏輯的情況下更簡單的開發(fā)。但它將這個負(fù)擔(dān)會轉(zhuǎn)移到我們代碼的未來讀者身上。他們將不得不在沒有上下文和編譯器幫助的情況下解釋發(fā)生了什么。

(6) 有了文檔，我可以提供所有上下文

添加類型時，我們會從編譯器獲得幫助，并且會獲得不會隨時間推移而衰減的文檔，因?yàn)槿绻^時了，我們的代碼將無法編譯。

const intersection = (a: any, b: any): any => { 
... 
} 
const intersection = ( 
  a: Set<number>, b: Set<number> 
): Set<number> => { 
... 
} 

它們都是等效的，但是讀者會更好地了解后面的函數(shù)在做什么，而不是從第一個函數(shù)開始。

(7) 我已經(jīng)通過必要的運(yùn)行時檢查以防御性的方式編寫了代碼，以確保沒有錯誤

現(xiàn)在可能沒有錯誤，但是除非你有很好的測試覆蓋率，否則以后來修改代碼的人不會相信他們不是在錯誤中重構(gòu);就好像編譯器不會幫你，因?yàn)槲覀冋f過它不會幫你。如果我們顯式地設(shè)置類型并更改系統(tǒng)中使用的API，編譯器將提供它的指導(dǎo)。

(8) 如果以后我改變主意怎么辦?我可能會為此重構(gòu)幾個小時

我們總是可以修改和適應(yīng)新的類型定義， TypeScript 為此提供了一組實(shí)用功能。我們可以 Pick 習(xí)慣從先前定義的類型中選擇所需的屬性。Omit 得到除少數(shù)幾個以外的所有東西。Partial 使所有屬性都是可選的，或進(jìn)行完整的180并使其全部Requireds。

type User = { 
  id: number; 
  firstName: string; 
  lastName: string; 
  age: number; 
} 
 
type UserParams = 
  Pick<User, "id"> & Partial<Omit<User, "id">> 
 
const updateUser = ( 
  { id, ...newUserParams }: UserParams 
) => { 
  {...} 
} 

(9) 很好，從TypeScript中刪除 any，立即打開PR

讓我們深吸一口氣， any 它在正確的情況下非常強(qiáng)大且有用。

• 與使用它的庫接口;確保在將數(shù)據(jù)移至系統(tǒng)之前盡快將其轉(zhuǎn)換為正確的類型。
• 解決 TypeScript 類型錯誤;如果我們發(fā)現(xiàn)自己無法輸入某些內(nèi)容，則 any 可能有必要。但是只有在嘗試其他所有方法之后才推薦使用。如果使用它，我們應(yīng)該將其重新轉(zhuǎn)換為可預(yù)測的類型。
• 如果我們的函數(shù)可以真正處理任何類型，那么這種情況很少見，并且是偶然的(例如調(diào)試或日志記錄函數(shù))。在這些情況下，我們需要 100% 確保不存在會導(dǎo)致函數(shù)失敗的類型。我們應(yīng)該檢查函數(shù)的主體，并根據(jù)輸入確定最基本的形狀并加以限制。例如，如果我們要打印某些內(nèi)容，則至少應(yīng)驗(yàn)證它是否響應(yīng) toString 。

讓我們回顧一下

為什么我們不能在使用 any ?

• 它使編譯器過時了，我們告訴編譯器：我不需要你的幫助
• 我們放棄了在編寫代碼時記錄代碼的機(jī)會
• 我們的第一道防線被攻破了
• 在動態(tài)語言中，我們假設(shè)事物可以有 any 類型，我們采用的模式遵循這個假設(shè)。如果我們開始使用靜態(tài)類型語言作為動態(tài)語言，那么我們就是在與范式作斗爭
• 當(dāng)我們繼續(xù)對代碼庫進(jìn)行更改時，沒有什么可以指導(dǎo)/幫助我們。
• 自由越大，責(zé)任越大(編譯器)。不要變成一個編譯器，我們的目的是使用編譯器。