沉默的性能殺手：理解與消除現代開發中的死碼

未使用代碼的隱藏成本

每個程式碼庫都會積累包袱。宣告但從未調用的函數。賦值但從未引用的變數。引入但閒置的模組。這些積累的死代碼不僅使你的專案變得雜亂——它還會積極地拖慢性能並增加維護負擔。

當功能演進時，較舊的實作就像考古層一樣殘留。後果逐漸累積：你的打包文件膨脹，建置時間變慢，新團隊成員在不必要的複雜性中摸索，安全漏洞藏匿在被遺忘的角落。死代碼是默默累積的技術債，直到你被迫面對它。

什麼算是死代碼？

死代碼在你的程式碼庫中有多種形式：

類型 1：變數墓地
宣告並初始化但從未被後續邏輯使用的變數。

類型 2：孤立的函數與方法
不再被任何地方調用的函數定義。

類型 3：多餘的引入
引入但從未在程式碼中實際使用的模組。

類型 4：已導出但無法到達
作為導出從模組中發布，但系統的其他部分未導入的元件或函數。

類型 5：孤立的檔案
整個檔案——元件、工具函數、模組——與應用流程脫節。

類型 6：幽靈依賴
在 package.json 中的套件條目，但程式碼庫從未實際調用或引用。

值得謹慎處理的灰色區域：

• 暫時禁用的功能，預留未來重新啟用，應標記而非盲目刪除
• 工具函數或輔助函數應定期檢查，而非立即移除，因為它們常作為安全網

發現死代碼：工具選擇

多種專用工具擅長死代碼檢測。你的選擇取決於你的技術棧與特定需求：

ts-prune：專門針對 TypeScript 項目，定位未使用的導出符號、常數與型別定義。(目前處於維護模式，沒有活躍更新)

depcheck：專注於 npm 依賴分析，揭示被遺棄或缺失的套件。

knip：一個全面的解決方案，能檢測未使用的依賴、孤立的導出與脫節的檔案，這是驅動現代清理流程的工具。

使用 knip 消除死代碼的逐步指南

設置階段

首先，將 knip 安裝到你的專案環境中：