打個比方，便於理解

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

以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 的結構就要改對應的型別宣告，這真的很麻煩。

團隊開發的強型別最好，因為經常需要改其他人程式碼，這也是為啥java和typescript能火。自己玩的，演算法類的，ai的，弱型別方便，弱型別一行程式碼，強型別可能需要寫10行，但是也難理解。總之團隊開發的就強型別。

動態型別有利有弊吧，作為資料交換來說動態型別的序列化意義很大，介面上可以減少很多邏輯程式碼，但是規範很重要；PHP最大的問題不是語言本身，而是很多開發者不注意開發規範，PHP是最容易學習但是最不容易讓人接手的語言，你要是遇到個二貨程式設計師你恨不得要重寫程式碼……

這話跳過了具體環境是無意義的。語言若是支援動態型別，那麼它原則上應有檢測某資料型別的機制，在操作方，使用資料之前都應先判斷其資料型別，不按這種規範做，當然火葬場。事實上，C語言也有動態型別的性質，傳入一個整數，你可以把它當指標用，最典型的把整數視為字元，這就是火葬場，但為什麼有人會偏愛這種語言呢？所以這不是動態型別的問題，是使用者自己的問題。提供了一套機制，自然有它的規範用法，自己不遵守，去怪人家提供這樣的東西，是說不過去的。

動態型別需要有嚴厲的程式碼規範，比如類成員，半路新增一個成員，就開發自己知道，如果有一天這個成員要變更，接手的人只能大海撈針。再說鴨子型別，本意是用來增強功能，擺脫繼承的累贅。可是鴨子型別重構起來也麻煩。專案越大，越需要靜態語言，起碼它的結構是清晰的，容易尋根問底的。動態語言規範上不要求的話，它要執行時結構才完備，甚至執行時在不斷變化。