一個不要你上傳建置產物的預算工具
打包分析器是少數幾乎每個選項都要求你上傳「正在分析的東西」的工具類別之一。對建置產物來說這是個奇怪的要求：它是你私有程式碼編譯、minify 壓縮、附上 source map 之後的版本，而一個 dist 資料夾常常好幾百 MB。這個頁面改成在本機讀取——資料夾用 File API 解析，每個檔案則在分頁裡用 `CompressionStream` 壓成 gzip，跟伺服器實際送出的演算法是同一個。
有三個決定塑造了這個工具回報的內容：
- 「進入點」是一個閉包，不是一個旗標。 Vite 會把共用的相依套件拆進 vendor chunk，它們既不是進入點、也不是動態進入點——但它們仍然會在頁面能互動之前送達。分析器從真正的進入點出發，沿著 manifest 的 imports 一路追下去，所以首次繪製的數字是訪客實際下載的量，而不是一個好看的子集。
- 這裡的 gzip 就是你的伺服器會送出的那個。 每個文字資源在回報之前都會先在分頁裡壓縮，所以數字對得上設定了 gzip 的伺服器，而不是一個樂觀的估計值。已經壓縮過的檔案（字型、圖片）不會再壓一次；頁面會直接講明，而不是假裝它們也會變小。
- 不只給表格，還給判定。 設定每個 chunk 的預算、JavaScript 總量預算與單一資源預算，分析器就會告訴你哪個檔案超過哪一項上限、超了多少——跟這個網站自我要求的效能預算同一個形狀。報告可以複製成 Markdown，貼進 PR 說明。
關於這些數字，有兩點誠實的補充。source map 會單獨回報，因為除非 devtools 主動要求，訪客永遠不會下載它們——它們體積龐大，否則會佔據每一份「最大檔案」清單。另外你的伺服器可能偏好 Brotli，它通常比這裡顯示的 gzip 再小 15-20%；如果你的主機有開啟，實際傳輸量會比這份報告更小。這份報告不會告訴你的是某個 chunk 為什麼這麼大——那件事你還是需要原始碼層級的視覺化工具，但你已經不必把建置產物交給別人的伺服器，才能知道該去看哪個 chunk。