你的JS包為什么偷偷膨脹到2MB

打開(kāi)Chrome DevTools，看到一個(gè)2MB的壓縮包，你可能覺(jué)得"還行"。但在一部中端安卓機(jī)上，V8引擎要花12秒解析編譯——用戶(hù)盯著白屏，連按鈕都點(diǎn)不了。

這不是邊緣場(chǎng)景。這是全球60%用戶(hù)的日常。

打包器的默認(rèn)陷阱

運(yùn)行npm run build時(shí)，Rollup、Webpack或esbuild會(huì)做一件事：把所有東西塞進(jìn)一個(gè)文件。你的組件、工具函數(shù)、整個(gè)lodash庫(kù)、一千個(gè)圖標(biāo)——全部打包。

為什么默認(rèn)這么做？因?yàn)镠TTP請(qǐng)求有開(kāi)銷(xiāo)。一個(gè)文件意味著一次連接、一份緩存、最少的往返。對(duì)小型應(yīng)用，這是對(duì)的優(yōu)化。

但當(dāng)你的vendor代碼超過(guò)應(yīng)用代碼，當(dāng)某個(gè)日期庫(kù)因?yàn)橐淮胃袷交{(diào)用拖進(jìn)300KB，當(dāng)用戶(hù)只需要首頁(yè)卻下載了整個(gè)單頁(yè)應(yīng)用——"一個(gè)大文件"就從資產(chǎn)變成負(fù)債。

先看見(jiàn)，才能優(yōu)化

別猜。用工具看。

rollup-plugin-visualizer給Vite/Rollup項(xiàng)目生成交互式樹(shù)圖。配置里加幾行，build完打開(kāi)HTML，矩形面積就是模塊體積。一眼掃過(guò)去，vendor塊有沒(méi)有意外之客，清清楚楚。

Webpack用戶(hù)用webpack-bundle-analyzer。裝完跑兩條命令，JSON轉(zhuǎn)可視化，同樣的樹(shù)圖邏輯。

如果連插件都懶得配，source-map-explorer直接分析產(chǎn)物文件。有source map就能跑。

看圖時(shí)盯三個(gè)信號(hào)：?jiǎn)蝹€(gè)文件超過(guò)100KB的vendor依賴(lài)、重復(fù)出現(xiàn)的同類(lèi)庫(kù)（比如兩個(gè)日期處理庫(kù)）、只在特定路由用到的代碼卻躺在主包里。

搖樹(shù)：為什么有時(shí)候搖不掉

Tree shaking（搖樹(shù)優(yōu)化）靠ES模塊的靜態(tài)結(jié)構(gòu)。導(dǎo)入導(dǎo)出在編譯時(shí)確定，沒(méi)用到的代碼理論上該被剔除。

但"理論上"經(jīng)常翻車(chē)。常見(jiàn)死因：CommonJS混用、動(dòng)態(tài)屬性訪問(wèn)、副作用未聲明。

package.json里的sideEffects字段是控制閥。設(shè)為false，打包器敢大膽刪；設(shè)為數(shù)組，列出的文件保留，其余優(yōu)化。很多庫(kù)沒(méi)配這個(gè)，導(dǎo)致整包保留——哪怕你只導(dǎo)入了一個(gè)函數(shù)。

代碼分割：按需的哲學(xué)

動(dòng)態(tài)import()是分割點(diǎn)。寫(xiě)法像普通導(dǎo)入，但返回Promise，打包器自動(dòng)拆成獨(dú)立chunk。

用戶(hù)點(diǎn)到"設(shè)置"頁(yè)面才去下載設(shè)置頁(yè)的代碼。首屏包瘦身，交互時(shí)間驟降。這不是懶加載的裝飾，是性能預(yù)算的重新分配。

路由級(jí)分割、組件級(jí)分割、甚至函數(shù)級(jí)分割——粒度越細(xì)，初始下載越小。代價(jià)是運(yùn)行時(shí)管理更多請(qǐng)求，需要權(quán)衡。

一個(gè)檢查清單

下次發(fā)版前，跑一遍：用可視化工具掃描包體積、檢查sideEffects配置、把路由改成動(dòng)態(tài)導(dǎo)入、驗(yàn)證3G下的首屏?xí)r間。

2MB的gzip包在開(kāi)發(fā)者電腦上秒開(kāi)，在用戶(hù)手里是12秒的沉默。這個(gè)差距，就是優(yōu)化空間。