2024年Stack Overflow開(kāi)發(fā)者調(diào)查里，有個(gè)數(shù)據(jù)被大多數(shù)人忽略了——在"最常用工具"榜單上，包管理器的滿意度分化比框架本身還劇烈。npm以67%的使用率穩(wěn)居第一，但"愿意繼續(xù)使用"的比例只有54%。與此同時(shí)，pnpm的使用率僅11%，推薦意愿卻高達(dá)78%。

這組數(shù)字說(shuō)明一件事：大多數(shù)人用著默認(rèn)工具，但知道更好選擇的人已經(jīng)回不去了。

2025年的JavaScript生態(tài)里，四個(gè)包管理器各自占據(jù)不同生態(tài)位。npm是空氣，無(wú)處不在；Yarn是遺產(chǎn)，維護(hù)著舊帝國(guó)的邊界；pnpm是效率狂的私藏；Bun則是新貴，帶著運(yùn)行時(shí)一起砸場(chǎng)子。它們都能把代碼裝到本地，但"怎么裝"這件事，已經(jīng)分化出四條完全不同的技術(shù)路線。

npm：從"能用"到"還行"，花了7年

npm 10在2025年的表現(xiàn)，放在五年前會(huì)被當(dāng)成科幻片。冷啟動(dòng)安裝200個(gè)依賴，30-40秒完成。這個(gè)數(shù)字在npm 6時(shí)代是3分鐘以上，而且中途崩潰的概率不低。

速度追上來(lái)了，但磁盤開(kāi)銷仍是硬傷。每個(gè)項(xiàng)目的node_modules都是獨(dú)立王國(guó)，300個(gè)依賴膨脹到300-500MB是常態(tài)。十個(gè)項(xiàng)目就是3-5GB的重復(fù)存儲(chǔ)，SSD用戶也開(kāi)始皺眉。

npm Workspaces（v7引入）解決了多包倉(cāng)庫(kù)的基礎(chǔ)需求，但hoisting機(jī)制帶來(lái)的"幽靈依賴"問(wèn)題至今讓人頭疼。你明明沒(méi)裝某個(gè)包，卻能require進(jìn)來(lái)，CI環(huán)境一跑就報(bào)錯(cuò)。這種"本地能跑"的幻覺(jué)，調(diào)試成本往往比直接報(bào)錯(cuò)更高。

package-lock.json的冗長(zhǎng)是另一道風(fēng)景。一個(gè)中型項(xiàng)目的鎖文件輕松突破5萬(wàn)行，代碼審查時(shí)滑半天找不到有效信息。但好處是生態(tài)兼容性——每個(gè)安全掃描工具、每個(gè)CI系統(tǒng)都認(rèn)得它，這是二十年積累的基礎(chǔ)設(shè)施紅利。

npm的真正護(hù)城河從來(lái)不是技術(shù)，而是"默認(rèn)"。Node.js安裝包自帶，教程默認(rèn)提及，新人零門檻上手。這種路徑依賴構(gòu)成的壁壘，比任何功能特性都更難打破。

Yarn：一場(chǎng)分裂造就兩個(gè)物種

Yarn的歷史是技術(shù)史上最典型的"第二代困境"。2016年Facebook推出Yarn Classic，用鎖文件和并行下載把npm按在地上摩擦。2020年Yarn Berry（v2+）發(fā)布，徹底重寫架構(gòu)，引入Plug'n'Play——然后社區(qū)裂成兩半。

分裂至今沒(méi)有愈合。Yarn Classic仍在維護(hù)模式接收安全補(bǔ)丁，但新功能凍結(jié)。大量存量項(xiàng)目依賴yarn.lock，遷移成本讓它們困在v1。Yarn Berry的PnP機(jī)制理論上更優(yōu)：包存在全局zip緩存，通過(guò)loader解析，徹底消滅node_modules黑洞。

但PnP的兼容性代價(jià)是真實(shí)的。不少原生模塊、舊版工具鏈需要額外配置才能跑通。Yarn Berry團(tuán)隊(duì)做了大量兼容層，但"能跑"和"跑得順暢"之間總有縫隙。

Yarn Berry的零安裝（Zero-Installs）是另一個(gè)被低估的特性。把緩存提交到Git，CI直接跳過(guò)下載步驟。對(duì)于網(wǎng)絡(luò)環(huán)境復(fù)雜的團(tuán)隊(duì)，這是救命功能。但代價(jià)是倉(cāng)庫(kù)體積暴漲，權(quán)衡并不總是值得。

選擇Yarn的人，本質(zhì)上是在選擇一種工程文化：愿意接受一定復(fù)雜性，換取確定性的性能收益。這種 trade-off 在大型團(tuán)隊(duì)里更容易被接受——有專人維護(hù)工具鏈，個(gè)體開(kāi)發(fā)者感知到的摩擦被組織消化了。

pnpm：磁盤效率的暴力美學(xué)

pnpm的技術(shù)路線可以用一個(gè)類比理解：npm像每個(gè)項(xiàng)目各自買全套工具，pnpm像社區(qū)共享工具庫(kù)，用時(shí)去取。全局內(nèi)容尋址存儲(chǔ)（content-addressable store）讓同一個(gè)包版本只存一份，硬鏈接到各項(xiàng)目的node_modules。

實(shí)測(cè)數(shù)據(jù)很直觀。10個(gè)項(xiàng)目都依賴lodash@4.17.21，npm存10份，pnpm存1份。磁盤節(jié)省比例隨項(xiàng)目規(guī)模遞增，單開(kāi)發(fā)者機(jī)器上省出幾十GB并不夸張。CI環(huán)境的緩存效率同樣提升，因?yàn)榫彺骀I的命中率更高。

速度方面，pnpm與Yarn Berry處于同一梯隊(duì)，顯著快于npm。內(nèi)容尋址存儲(chǔ)的副作用是"秒級(jí)復(fù)用"——曾經(jīng)下載過(guò)的包，新項(xiàng)目安裝時(shí)幾乎無(wú)感知。

pnpm的嚴(yán)格依賴樹(shù)是另一張王牌。默認(rèn)不允許訪問(wèn)未聲明的依賴，幽靈依賴問(wèn)題從源頭消失。這對(duì)大型monorepo至關(guān)重要——包之間的隱式耦合是技術(shù)債的溫床，pnpm的嚴(yán)格性相當(dāng)于強(qiáng)制性的代碼審查。

Workspace功能的設(shè)計(jì)也體現(xiàn)出對(duì)monorepo場(chǎng)景的深度理解。過(guò)濾命令（--filter）讓開(kāi)發(fā)者精準(zhǔn)操作子集，任務(wù)編排（pnpm run --parallel）替代了專門的工具如lerna。很多團(tuán)隊(duì)砍掉了一層工具鏈復(fù)雜度。

React、Vue、Astro的新項(xiàng)目模板紛紛默認(rèn)pnpm，這不是偶然。框架作者對(duì)開(kāi)發(fā)者體驗(yàn)的敏感度，讓他們更早意識(shí)到磁盤和速度的長(zhǎng)期價(jià)值。

Bun：帶著運(yùn)行時(shí)一起掀桌

Bun的特殊性在于，它根本不是純粹的包管理器。Jarred Sumner在2022年發(fā)布的這個(gè)工具，把JavaScript運(yùn)行時(shí)、打包器、測(cè)試運(yùn)行器、包管理器塞進(jìn)同一個(gè)二進(jìn)制文件。包管理只是它的四分之一功能，但單拎出來(lái)已經(jīng)能打。

速度是Bun最直觀的標(biāo)簽。用Zig語(yǔ)言編寫，直接操作syscall，繞過(guò)Node.js的抽象層。安裝依賴的速度比pnpm再快30-50%，這種差距在大型項(xiàng)目上會(huì)被放大到"體感明顯"的級(jí)別。

但Bun的包管理器與Node.js生態(tài)的兼容性仍在追趕。2024年底的1.0版本解決了大部分阻塞性問(wèn)題，邊緣案例依然存在。某些postinstall腳本、原生模塊的編譯場(chǎng)景，Bun的處理方式與npm有微妙差異。

更深層的問(wèn)題是鎖定策略。Bun使用bun.lockb二進(jìn)制鎖文件，體積小巧、解析飛快，但生態(tài)工具鏈的支持度遠(yuǎn)不及package-lock.json和yarn.lock。安全掃描、依賴分析、SBOM生成，這些企業(yè)級(jí)流程的適配需要時(shí)間。

選擇Bun的人，本質(zhì)上是在押注一個(gè)更激進(jìn)的未來(lái)：JavaScript工具鏈的重新統(tǒng)一。如果Bun的運(yùn)行時(shí)市場(chǎng)份額持續(xù)增長(zhǎng)，它的包管理器會(huì)獲得天然的協(xié)同優(yōu)勢(shì)。但這條路的風(fēng)險(xiǎn)同樣真實(shí)——技術(shù)棧的押注錯(cuò)誤成本，在2025年仍然高昂。

2025年的選擇矩陣

沒(méi)有 universally correct 的答案，但有清晰的決策路徑。

團(tuán)隊(duì)規(guī)模小、項(xiàng)目數(shù)量少、追求零配置——npm 10已經(jīng)足夠。它的改進(jìn)被低估了，"默認(rèn)"本身就有工程價(jià)值。

維護(hù) legacy 項(xiàng)目，yarn.lock 已經(jīng)存在——Yarn Classic是務(wù)實(shí)選擇。遷移到Berry的收益，往往不值得測(cè)試覆蓋的成本。

大型monorepo、磁盤敏感、CI賬單刺眼——pnpm是當(dāng)前的最優(yōu)解。它的設(shè)計(jì)哲學(xué)與這類場(chǎng)景天然契合，社區(qū) momentum 也在向上。

愿意承擔(dān)風(fēng)險(xiǎn)、追求極致速度、或者已經(jīng)在用Bun運(yùn)行時(shí)——bun install是合理嘗試。但建議保留npm作為fallback，關(guān)鍵流程的兼容性驗(yàn)證不可跳過(guò)。

一個(gè)容易被忽略的細(xì)節(jié)：Corepack。Node.js 16.13+內(nèi)置的這個(gè)工具，讓切換包管理器變得無(wú)痛。corepack enable之后，項(xiàng)目目錄下的packageManager字段自動(dòng)鎖定版本，團(tuán)隊(duì)協(xié)作的"我用yarn你用npm"問(wèn)題基本消失。

2025年的包管理器戰(zhàn)爭(zhēng)，本質(zhì)上是"默認(rèn)夠用"與"優(yōu)化值得"兩條路線的博弈。npm守住了前者，pnpm和Bun證明了后者的市場(chǎng)空間。Yarn的分裂則是個(gè)警示：技術(shù)迭代中的連續(xù)性斷裂，代價(jià)往往由用戶承擔(dān)。

你的node_modules今天占了多少G？