程式碼壓縮到底對你的檔案做了什麼

你查看任何大型網站的原始碼，看到的都是一堵壓縮過的、無法閱讀的JavaScript牆。變數名稱是單個字母。沒有空格。所有程式碼在一行上。

那就是壓縮後的程式碼。它的存在有充分的理由。

壓縮做了什麼

壓縮透過刪除瀏覽器執行程式碼不需要的所有內容來減小檔案大小。程式碼行為完全相同。只是更小了。

空白刪除。 那些讓程式碼可讀的空格、定位字元和換行符？瀏覽器不在乎。刪掉。

註解刪除。 註解是給人看的。瀏覽器反正會跳過。刪掉。

變數縮短。 你精心命名的userAuthenticationToken變成了a。程式碼照樣運行。

死碼消除。 從未被呼叫的函式、從未被讀取的變數、永遠不會執行的程式碼路徑。進階壓縮工具會偵測並刪除它們。

語句最佳化。 if (condition) { return true; } else { return false; }變成return condition。同樣的邏輯，更少的位元組。

真實數據

節省效果很可觀。JavaScript的典型壓縮率：

| 技術 | 體積減少 | |------|---------| | 空白 + 註解 | 30-40% | | 變數縮短 | 10-20% | | 死碼消除 | 5-15% | | 語句最佳化 | 2-5% | | 總計（gzip前） | 40-60% | | 加上gzip壓縮 | 70-85% |

500KB的JavaScript套件在壓縮後通常變為200-300KB，gzip後變為75-150KB。每次頁面載入都是實實在在的頻寬節省。

CSS也接受類似處理。刪除空白、縮短顏色代碼（#ffffff變#fff）、合併重複選擇器，通常能減少CSS的30-50%。

開發 vs 正式環境

永遠不要用壓縮後的程式碼工作。它不可讀，無法除錯。

你的建置流程應該自動處理這些：

• 開發： 原始的、可讀的程式碼，有註解和描述性命名
• 正式環境： 建置工具產生的最佳化輸出

大多數現代框架（Next.js、Vite、webpack）開箱即用地做到這一點。你寫乾淨的程式碼。建置工具產出最佳化的輸出。

Source map：除錯壓縮後的程式碼

Source map是壓縮後的正式環境程式碼和原始原始碼之間的橋樑。它們是獨立的檔案（通常是.map），將壓縮程式碼中的每個位置對映回原始位置。

正式環境出錯時，堆疊追蹤指向app.min.js的第1行第34872欄。沒用。但有了source map，瀏覽器開發者工具（或錯誤追蹤服務）就能顯示原始檔案、行號和變數名稱。

Source map應該：

• 在建置過程中產生
• 對錯誤追蹤工具（Sentry、Bugsnag等）可用
• 在正式環境中不公開存取（它們會暴露原始碼）

什麼時候不該壓縮

開發期間。 顯然。你需要讀取和除錯程式碼。

發佈的函式庫。 同時提供壓縮和未壓縮版本。讓使用者自己選擇。

伺服器端程式碼。 Node.js不關心檔案大小。檔案只載入一次。壓縮伺服器程式碼只會讓除錯更難。

HTML（通常）。 HTML壓縮的節省效果很小（10-15%），有時還會出問題。風險回報比不高。大多數團隊跳過。

超越壓縮

壓縮只是效能拼圖的一塊：

Gzip/Brotli壓縮。 伺服器壓縮回應。與程式碼壓縮結合效果最大。

程式碼拆分。 不要一次性傳送所有JavaScript。按路由或功能拆分，按需載入。

Tree shaking。 只匯入函式庫中你使用的函式，讓打包工具刪除其餘部分。

你可以用文字比較並排比較原始和壓縮後的程式碼，或用字元計數器測量精確的體積減少。

---

壓縮是免費的效能提升。在建置流程中設定一次就忘掉它。使用者獲得更快的載入速度，你節省頻寬成本，程式碼在重要的地方——你的編輯器裡——保持可讀。