第6章 靜態類型檢查：Flow.js和TypeScript

如果你一直使用原生的JavaScript語言編寫程序，沒有接觸過其他編程語言，或許會對“代碼靜態類型檢查”的概念感到陌生。在介紹什么是“代碼靜態檢查”之前，需要先介紹靜態類型語言和動態類型語言的定義。靜態類型語言是指在編譯時就能確定各個變量的類型，所以在代碼運行之前，就可以對其進行類型檢查，自然在程序運行之前也就可以發現其中一些潛在的問題。而動態類型語言是指在編譯時并不知道變量的確切類型，變量的類型可以通過賦值改變，所以只能等程序運行時才能獲取變量的準確類型，如果程序中存在類型錯誤，代碼可能會直接報錯，嚴重時還會導致程序退出。

JavaScript就是一門動態類型語言，一般在開發初期，需要更快地開發出應用原型，動態類型可以提供更好的編程體驗，使開發者可以更專注于業務邏輯的程序設計，而不必糾結于如何為每一個聲明的變量指定正確的類型。既然如此，那為什么還要引入靜態類型呢？動態類型的靈活性并不是沒有成本的，靈活性必然會帶來編碼的多樣性和隨意性，這無疑會增加調試和維護的難度。試想，你編寫的程序在運行時報出一個錯誤，你根據錯誤中的堆棧信息找到相關代碼之后，發現它只是一個低級錯誤，盡管你很快就可以將它修復好，但問題還遠遠沒有結束，比如修改后的代碼就一定是正確的嗎？其他代碼會受到影響嗎？還有沒有類似的問題也會引起報錯？這些你都無法確定，只有再次運行程序才可能確定。這會使調試的過程變得枯燥且艱難，你不得不花費大量的時間一次次重新運行代碼，然后依靠報錯信息來找出自己或其他人在程序中留下的錯誤。當你花了好幾個小時調試代碼，最終卻發現是別人的代碼導致的錯誤時，那種感覺真的是一言難盡。

為了解決上面的問題，我們需要在源代碼的基礎上引入一層類型系統，靜態類型的引入為語言增加了靜態類型檢查的能力，從而使得開發者不必運行代碼就可以檢測出明顯的語法錯誤，另外，它還可以用來共享接口定義或類定義等一些公共的定義信息。這些看似多余的做法都是為了能夠讓JavaScript在現代前端開發中承擔更多的責任，而不只是被當作一種“玩具”語言。

本章將介紹靜態類型檢查的相關知識，以及兩種流行的靜態類型檢查方案Flow.js和TypeScript的使用方法。