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

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

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

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

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

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

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

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

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

Yarn：一場分裂造就兩個物種

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

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

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

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

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

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

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

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

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

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

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

React、Vue、Astro的新項目模板紛紛默認(rèn)pnpm，這不是偶然?？蚣茏髡邔﹂_發(fā)者體驗的敏感度，讓他們更早意識到磁盤和速度的長期價值。

Bun：帶著運行時一起掀桌

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

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

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

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

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

2025年的選擇矩陣

沒有 universally correct 的答案，但有清晰的決策路徑。

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

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

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

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

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

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

你的node_modules今天占了多少G？