為什么說「動態類型一時爽？

打個比方，便于理解

你寫一個允許傳入動態類型的函數給別人用，就如同給一張簽了名的空白支票別人一樣危險，別人愛寫什么數字上去都行。

以Facebook為例，Facebook 有一種數據類型叫做 FBID，是一個 64 位的整數，用作任何對象的唯一 ID。

在 Facebook 把無類型的 PHP 轉化為有類型的 Hack 之前，很多人不知道 FBID 是整數還是字符串，于是有些函數用整數接收 FBID，另外一些函數用字符串。

到最后，函數間傳遞的 FBID 到底是什么類型已經說不清楚。

導致的結果就是：你寫一個函數，中間接收了一個 FBID 的數組，你永遠不可能知道 FBID 屬于哪種類型，甚至可能是混合類型的。

在語義上這絕對是有問題的，但神奇的 PHP 在做整數和字符串 “==” 比較時會自動把字符串隱式轉換為整數，所以原本不應該相等的兩種類型 FBID 可能會被判定為相等。不過如果用 === 的話，不同類型自然不相等。因為很多人不注意細節，使用 == 而非 ===，所以如果假設你接收了一個 FBID 的數組，然后調用別人的函數來去重，你猜 “123” 和 123 會不會被當作重復而去掉？你不可能猜到，因為你不知道別人用什么做對比。

這使得當時 Facebook 的 PHP 代碼存在大量難以發現的 bug，而且沒人敢去修。你說你這里 FBID 一定是整數，然后收到字符串就拋異常？你猜你這一改 Facebook 哪些功能會掛掉？你不可能知道……所以你不敢改。

最終 Facebook 把 PHP 逐步轉化為 Hack，把 FBID 存儲為整數，大家就可以放心地把 FBID 傳來傳去不用擔心出問題了。如果你嘗試拿 FBID 跟另外一個字符串或整數比較，你的代碼在靜態分析階段就會報錯。你一定要比較，就必須進行顯式類型轉換后再做比較。

同理，Facebook 把 JavaScript 改造為 Flow，但 FBID 在 JavaScript 里面必須存儲為字符串，因為 JavaScript 存儲不了 64 位整數，可能會轉換為浮點數存儲，然后丟失精度。在此之前，有人不知道 FBID 在 JavaScript 不能存為整數，然后引發各種難以復現的 bug。

如果你不懂 Hack 或 Flow，可以用現在主流的 TypeScript 做參考。我認為這是現在最好的折衷方案。語言本身是支持動態類型的，但通過類型注釋來讓類型穩定的變量和參數變為有類型，你不加類型注釋的時候還能靈活使用動態類型。

因為你在開發新功能時，可能你只是在探索，具體數據結構還沒有定下來，不需要聲明完整的數據結構類型信息能為你節省不少改來改去的時間。與之對比的是那些 C++ 和 Java 操作 JSON 的代碼，必須處處聲明現在預期讀取出來的變量是什么類型，你稍微改一下 JSON 的結構就要改對應的類型聲明，這真的很麻煩。

以上，希望對你有用！