490KB的低頻功能：一次打包體積排查，攤開的是前端分發成本那本帳

2026年9月29日，掘金出現一篇前端工程實務文章，作者負責一個React 18加Vite的H5專案，生產構建後JS合計約2MB。作者花了一個下午排查，最後用rollup-plugin-visualizer生成的Treemap報告定位到最大色塊：一個名為mammoth的docx預覽庫，將近490KB，約佔整包JS的四分之一。

來源是開發者第一人稱的技術隨筆，數字均出自該文自述，本文以此為事實基礎，從成本結構角度拆這本帳。

這490KB是怎麼躺進去的

按作者描述，問題的成因很直白：協議預覽頁需要在本機轉換docx檔案，於是動態import(‘mammoth’)。這個功能使用頻率低，但套件的體積被完整計入構建產物，成為全專案最大的單一依賴。

這裡的關鍵數字是傳輸口徑的落差。作者在文中特別提醒，gzipSize要打開：原始490KB的套件，gzip後可能只有120KB出頭。換句話說，使用者實際下載的增量更接近120KB而非490KB，但這仍是為一個低頻功能預付的固定運輸成本。

這與我們先前分析的AI影片生成的單位成本結構是同一類問題：功能價值與其佔用的資源份額，在帳本上沒有對齊。

排查工具本身，是一張成本地圖

rollup-plugin-visualizer的運作方式，是在vite build之後產出一份stats.html，每個依賴模組呈現為一個色塊，面積對應體積。Vite底層用Rollup打包，外掛對Vite專案直接可用。

作者整理的四種視圖裡，Treemap矩形拼圖覆蓋九成日常場景，Network視圖用來追蹤套件是被哪條引入鏈帶進來的，List可匯出供CI比對。報告頁另有Rendered、Gzip、Brotli三種口徑切換，預設的Rendered是壓縮前體積。

工具的價值在於把猜測換成量測。翻package.json看不出誰最大，因為依賴名稱不帶體積資訊；Treemap把這個資訊視覺化之後，動刀順序就從「聽說antd-mobile很大」變成「mammoth 490KB排第一」。這本質上是把隱性成本顯性化，與企業財報裡把沉沒成本從報表註記拉到主表的邏輯相同。

影響傳導：誰在為低頻功能付費

受影響的傳導鏈可以拆成三層。第一層是使用者端，所有進入該H5的路徑若把mammoth計入主包或公共chunk，等於全體使用者為少數觸發協議預覽的會話分攤傳輸成本；若拆得乾淨，成本落在實際觸發者頭上，但仍是每次觸發都要下載的120KB級開銷。第二層是維運端，構建產物體積直接影響CDN流量費用與快取命中率，2MB的JS包在量大的H5場景是可量化的頻寬帳。第三層是開發端，排查時間本身是成本，作者自述花了一下午，而這半天在沒有視覺化工具的前提下可能換不來答案。

從對照角度看，這不是新鮮問題。前端社羣對bundle size的控制，從webpack時代的source-map-explorer到今天的各類visualizer，工具鏈持續在把「體積會計」標準化。每次框架換代或構建工具更替，同樣的排查就要重做一次，這也是工具鏈遷移成本的隱性組成部分。

收束判斷

這篇文章的可取之處，在於它給了一個可複製的量測流程而非空泛的方法論口號：構建時啟用visualizer、開gzipSize、看Treemap找最大色塊、再決定要不要動態加載或替換。490KB不是駭人的數字，但一個低頻功能佔全包四分之一，說明這個專案的體積預算沒有分配機制。

對任何JS產物超過1MB的前端專案，這套排查的投入產出比都成立。至於mammoth最終被拆掉還是換掉，來源文章未給出後續，這一欄暫時保留未知。