從去年年底開始我這邊維護(hù)的一個中后臺項(xiàng)目進(jìn)入密集迭代期Vite 的開發(fā)調(diào)試還算是順滑但生產(chǎn)構(gòu)建時間越來越讓人坐不住——從最初十幾秒一路漲到接近兩分鐘。每次發(fā)版前等著構(gòu)建跑完CPU 占用率卻只有 25% 上下四個核心八個線程絕大多數(shù)時間只有一個核心在忙其他都在旁邊圍觀。這種“跑滿一個核、餓死其他核”的狀態(tài)持續(xù)了很久直到我決定花點(diǎn)時間把 Worker Threads 引到構(gòu)建鏈路里才算是真正吃上了多核紅利。這篇文章就圍繞“用 Worker Threads 加速 Vite 構(gòu)建”這件事來寫。我不打算只扔結(jié)論而是把從現(xiàn)象分析、方案選型、代碼落地到上線后遇到的那些奇葩問題完整過一遍。整個優(yōu)化過程改動的核心代碼量其實(shí)不大但收益非常直觀生產(chǎn)構(gòu)建耗時從 110 秒壓到了 46 秒左右內(nèi)存峰值還更穩(wěn)了。無論你是對 Vite 插件機(jī)制有一定了解的前端工程師還是正在被構(gòu)建性能問題纏住的同學(xué)這篇文章應(yīng)該都能給你一些可以直接抄作業(yè)的思路。1. 為什么 Vite 構(gòu)建會卡在單核1.1 構(gòu)建耗時都花在哪了——先做一次真實(shí)拆解要優(yōu)化構(gòu)建第一步不是急著上多線程而是搞清楚時間到底消耗在哪個環(huán)節(jié)。Vite 的生產(chǎn)構(gòu)建鏈路和開發(fā)模式完全不同開發(fā)模式主要依賴 esbuild 做依賴預(yù)構(gòu)建配合瀏覽器原生 ESM 實(shí)現(xiàn)秒級啟動但生產(chǎn)模式會切換到 Rollup 作為打包內(nèi)核再加上各種插件鉤子、代碼壓縮、sourcemap 合并整個流程是串行異步混在一起跑的。我在項(xiàng)目里用vite build --debug和構(gòu)建日志里的時間戳做了一次粗略拆解發(fā)現(xiàn)耗時大頭集中在三個地方第一是業(yè)務(wù)代碼的 transform 階段項(xiàng)目里有不少自定義的模板語法需要做 AST 轉(zhuǎn)換這一塊單次執(zhí)行不算慢但文件數(shù)量上千之后累加起來非?？捎^第二是壓縮環(huán)節(jié)雖然我們用的是 esbuild 做 minify但遇上超大 chunk 時依然會卡出明顯的時間尖峰第三是 sourcemap 生成和文件寫入這部分在文件數(shù)量多的時候也會占用不少時間。當(dāng)時我在任務(wù)管理器里觀察構(gòu)建過程中的 CPU 趨勢圖發(fā)現(xiàn)一個很有意思的現(xiàn)象整個構(gòu)建流程的 CPU 使用率呈現(xiàn)明顯的“鋸齒狀”——某個階段單核飆到 100%其他核心閑置切換到下一個階段后剛才滿載的核心又開始休息另一個核心接著忙。這就說明構(gòu)建任務(wù)整體是串行的沒有把多核資源利用起來。而 Node.js 默認(rèn)模型下JavaScript 代碼只跑在單個線程上Vite 雖然內(nèi)部用了 esbuild 這種 Go 寫的原生工具來做并行處理但大量 JS 插件邏輯仍然被限制在單線程里。如果你的項(xiàng)目只是中小型規(guī)模構(gòu)建 20 秒內(nèi)能搞定那其實(shí)沒必要折騰多線程優(yōu)化收益不明顯還增加復(fù)雜度。但如果構(gòu)建時間超過 40 秒并且明顯能觀察到 CPU 多核利用率不平衡那 Worker Threads 就是一條值得走的路。1.2 Node.js 的單線程模型與 Worker Threads 的適用邊界很多人對 Node.js 單線程的理解有一個誤區(qū)以為所有代碼都是單線程的。準(zhǔn)確地說JavaScript 執(zhí)行邏輯默認(rèn)跑在單個線程上但文件 I/O、網(wǎng)絡(luò)請求等系統(tǒng)調(diào)用是通過 libuv 線程池來異步處理的。這就導(dǎo)致一個結(jié)果——I/O 密集型任務(wù)讀文件、跑 http 請求天然不會阻塞主線程但 CPU 密集型任務(wù)AST 轉(zhuǎn)換、JSON 序列化、復(fù)雜計(jì)算會真實(shí)地卡住主線程。Worker Threads 的工作原理是在同一個進(jìn)程內(nèi)創(chuàng)建獨(dú)立的工作線程每個線程有獨(dú)立的 V8 實(shí)例和事件循環(huán)線程之間通過postMessage傳遞消息來通信。這比 child_process 那種進(jìn)程級并發(fā)的開銷要小得多因?yàn)榫€程之間可以直接共享內(nèi)存通過 SharedArrayBuffer不需要走 IPC 的序列化和反序列化。但 Worker Threads 不是銀彈。它在數(shù)據(jù)傳遞上有兩個硬性約束第一通過postMessage傳數(shù)據(jù)時數(shù)據(jù)會被結(jié)構(gòu)化克隆算法序列化如果你傳的對象非常大序列化開銷可能會吃掉多線程帶來的收益第二每個 worker 都有自己的 V8 堆內(nèi)存占用會隨著 worker 數(shù)量線性增長線程開多了反而可能觸發(fā) OOM。因此適合放進(jìn) Worker Threads 的任務(wù)應(yīng)該是“CPU 計(jì)算耗時遠(yuǎn)大于數(shù)據(jù)傳遞耗時”的粗粒度任務(wù)而不是一兩毫秒就能搞定的小操作。把這個模型套到 Vite 構(gòu)建場景里我們自然能找到切入點(diǎn)項(xiàng)目里的自定義代碼轉(zhuǎn)換、依賴分析、路由表生成、國際化文案解析這些純計(jì)算邏輯把輸入傳進(jìn)去、產(chǎn)出結(jié)構(gòu)化的結(jié)果再傳回來就是非常適合 worker 化的任務(wù)。2. 整體設(shè)計(jì)怎么把 Worker Threads 塞進(jìn) Vite 構(gòu)建流程2.1 先看 Vite 暴露了哪些擴(kuò)展接口要做這件事首先得弄清楚 Vite 的插件機(jī)制能讓我們在什么環(huán)節(jié)插入并行邏輯。Vite 插件體系借鑒了 Rollup 的鉤子設(shè)計(jì)但也有一些純 Vite 特有鉤子。對我們這次優(yōu)化最有價值的鉤子有三個第一個是transform鉤子每個模塊在加載之前都會經(jīng)過這一層轉(zhuǎn)換它接收code和id返回轉(zhuǎn)換后的代碼。這是最常見的代碼處理鉤子也是把自定義編譯邏輯插入構(gòu)建流程的主入口。第二個是configResolved鉤子它在 Vite 配置完全解析后觸發(fā)我們可以在此時讀取最終的配置項(xiàng)創(chuàng)建線程池。第三個是closeBundle鉤子在整個構(gòu)建結(jié)束或開發(fā)服務(wù)器關(guān)閉時觸發(fā)可以用來清理線程池避免進(jìn)程退出時 worker 還掛著。值得強(qiáng)調(diào)的是Vite 的插件鉤子本身是支持異步的我們可以很自然地在transform鉤子里等一個 worker 線程返回結(jié)果。這就為多線程改造提供了非常優(yōu)雅的接口——不需要改動 Vite 內(nèi)核只需要寫一個插件把原本同步執(zhí)行的轉(zhuǎn)換邏輯替換成異步的 worker 調(diào)用即可。但要特別注意Vite 內(nèi)部有緩存機(jī)制同一個文件在開發(fā)模式和生產(chǎn)構(gòu)建中可能被重復(fù)請求如果你的 worker 轉(zhuǎn)換邏輯有副作用比如修改了全局狀態(tài)那結(jié)果可能不可預(yù)期。所以設(shè)計(jì)上最理想的情況是讓 worker 保持“純函數(shù)”特性——同樣的輸入永遠(yuǎn)產(chǎn)出同樣的輸出只依賴傳入?yún)?shù)不依賴外部狀態(tài)。2.2 技術(shù)選型自己寫線程池還是用 piscina明確了插入點(diǎn)接下來要解決的是線程池的載體問題。最簡單的方式是直接new Worker()起一個 worker然后手動管理任務(wù)隊(duì)列。但生產(chǎn)環(huán)境沒那么簡單我們要處理并發(fā)請求、結(jié)果排序、錯誤重試、worker 退出后的重建這些代碼自己寫很容易出 bug。我在第一次嘗試時就是手寫了一個簡單的 worker 池代碼不到 100 行基本模型是先創(chuàng)建 N 個 worker每個 worker 空閑時從任務(wù)隊(duì)列里取任務(wù)執(zhí)行。跑下來發(fā)現(xiàn)兩個問題一是任務(wù)分配不均某些 worker 已經(jīng)空閑了但任務(wù)還在隊(duì)列里排隊(duì)二是異常處理很麻煩worker 里拋錯只能通過messageerror事件捕獲錯誤信息被序列化后常常丟失原始堆棧。后來換成了 piscina這是目前 Node 生態(tài)里比較成熟的線程池庫。它底層基于 Worker Threads但把任務(wù)分發(fā)、并發(fā)控制、優(yōu)先級、動態(tài)擴(kuò)展這些瑣事全都封裝好了。核心 API 很簡潔創(chuàng)建一個Piscina實(shí)例然后調(diào)用piscina.run(data, { name: taskName })就能把任務(wù)交給池子執(zhí)行返回的是一個 Promise。按我的使用經(jīng)驗(yàn)piscina 相比手寫方案最大的優(yōu)勢在于兩點(diǎn)。第一是任務(wù)調(diào)度更合理它內(nèi)部維護(hù)了一個任務(wù)隊(duì)列空閑 worker 會自動去取下一個任務(wù)配合 Atomics 等待機(jī)制不會出現(xiàn)某個 worker 閑著、任務(wù)卻排隊(duì)等另一個 worker 的情況。第二是支持多種 task 函數(shù)注冊你可以讓同一個池子處理多種不同類型的任務(wù)通過name字段區(qū)分這對我們后續(xù)擴(kuò)展其他編譯加速場景很有價值。如果項(xiàng)目不方便引入額外依賴手寫一個基本線程池也可以接受但我還是建議優(yōu)先用 piscina畢竟線程池本身就是一個容易踩坑的組件沒必要重復(fù)造輪子。2.3 線程池設(shè)計(jì)多少個 worker、任務(wù)分配和結(jié)果合并線程池的核心參數(shù)是 worker 數(shù)量。開太少了起不到加速效果開太多又會導(dǎo)致 CPU 上下文切換頻繁反而更慢。按照我實(shí)測的結(jié)果在 8 核 16 線程的機(jī)器上worker 數(shù)量設(shè)置為os.availableParallelism() - 1時效果最好也就是 7 個 worker。保留一個核心給主線程處理調(diào)度和其他 I/O 任務(wù)避免線程池把 CPU 全占滿后連構(gòu)建進(jìn)程本身都開始卡頓。這里順便提醒一句不要用os.cpus().length來獲取核心數(shù)因?yàn)?Node.js 18 及以后版本提供了os.availableParallelism()它會考慮 CPU 親和性和資源限制在容器環(huán)境下更準(zhǔn)確。我在公司測試機(jī)上用 Docker 跑構(gòu)建時os.cpus()會返回宿主機(jī)的核心數(shù)但實(shí)際可用的核數(shù)可能只有一半如果不注意這一點(diǎn)線程池就會創(chuàng)建過多 worker。任務(wù)分配方面piscina 采用的是“每個 worker 一次處理一個任務(wù)”的模型。當(dāng)transform鉤子被并發(fā)調(diào)用時多個文件會同時進(jìn)入 piscina 的任務(wù)隊(duì)列空閑的 worker 自動認(rèn)領(lǐng)并執(zhí)行。執(zhí)行完成后結(jié)果通過postMessage返回piscina 會按照任務(wù)提交的順序解析 Promise。這一點(diǎn)非常關(guān)鍵因?yàn)?Vite 在等待模塊轉(zhuǎn)換時可能同時發(fā)起多個請求如果結(jié)果亂序整個模塊圖就崩了。關(guān)于結(jié)果合并我的建議是單個文件的轉(zhuǎn)換結(jié)果不需要做額外的合并邏輯因?yàn)?Vite 本身就是按模塊維度做 transform 的每個模塊獨(dú)立處理返回的代碼直接替換原內(nèi)容即可。但如果你的 worker 處理的是像“一次性生成全站路由表”這樣的匯總型任務(wù)那就要考慮多 worker 之間結(jié)果重復(fù)計(jì)算的問題最穩(wěn)妥的方式是用一個專門的 worker 類似單例來處理這類任務(wù)否則每個 worker 都算一遍等于白費(fèi) CPU。3. 實(shí)操一個可運(yùn)行的 Vite Worker 加速插件3.1 插件原型把自定義 transform 塞進(jìn) worker 池講完設(shè)計(jì)思路直接上代碼。我這里寫一個簡化但完整可用的示例核心功能是當(dāng) Vite 在處理.vp后綴文件時原來會在主線程執(zhí)行一段 CPU 密集型的模板轉(zhuǎn)換邏輯現(xiàn)在我們把它挪到 worker 池里執(zhí)行。先裝依賴npm install piscina -D接著創(chuàng)建 worker 文件也就是真正執(zhí)行轉(zhuǎn)換邏輯的地方// template-worker.js const { parentPort } require(worker_threads); // 模擬一個比較消耗 CPU 的模板轉(zhuǎn)換函數(shù) function transformTemplate(code) { // 實(shí)際項(xiàng)目里這里可能是正則匹配、AST 遍歷、字符串拼接等重邏輯 let result code; for (let i 0; i 10000; i) { result result.replace(/__TEMPLATE__/g, value_${i}); } return result; } parentPort.on(message, (data) { const { id, code } data; try { const result transformTemplate(code); parentPort.postMessage({ id, result, error: null }); } catch (error) { parentPort.postMessage({ id, result: null, error: error.message }); } });然后寫 Vite 插件// vite-plugin-worker-transform.js const { Piscina } require(piscina); const path require(path); let piscina null; function createPool() { if (piscina) return piscina; piscina new Piscina({ filename: path.resolve(__dirname, template-worker.js), maxThreads: require(os).availableParallelism() - 1, // 讓 worker 常駐等待任務(wù) }); return piscina; } export default function viteWorkerTransform() { return { name: vite-worker-transform, enforce: pre, configResolved() { createPool(); }, async transform(code, id) { if (!id.endsWith(.vp)) { return null; } const pool createPool(); const result await pool.run({ id, code }); if (result.error) { throw new Error(Worker transform failed: ${result.error}); } return { code: result.result, map: null, }; }, async closeBundle() { if (piscina) { await piscina.destroy(); piscina null; } }, }; }這就是一個非常核心的骨架。你可能會問這么簡單的邏輯值得用 worker 嗎說實(shí)話模擬的這段代碼確實(shí)不值得。但在真實(shí)項(xiàng)目中把 transform 里的 CPU 密集段抽出來換成這個模型效果就很明顯了。關(guān)鍵點(diǎn)是enforce: pre這意味著我們的插件會在其他插件之前執(zhí)行避免后續(xù)插件拿到的是已經(jīng)被自定義轉(zhuǎn)換過的代碼時產(chǎn)生沖突。3.2 踩坑記錄worker 里拿不到 Vite 上下文的解決方案這個方案第一次真正跑起來后遇到的第一個問題來自業(yè)務(wù)代碼里依賴環(huán)境變量。原本我們在主線程的transform鉤子里可以輕松訪問config.env但把它挪進(jìn) worker 之后worker 線程和主線程的上下文完全隔離它根本不知道import.meta.env是什么東西。解決思路不是讓 worker 也能訪問 Vite 上下文而是把需要的配置在派發(fā)任務(wù)時顯式傳進(jìn)去。比如項(xiàng)目里定義了VITE_TEMPLATE_PREFIX環(huán)境變量那就在調(diào)用pool.run時把前綴一起傳const result await pool.run({ id, code, config: { prefix: process.env.VITE_TEMPLATE_PREFIX } });也就是說worker 的設(shè)計(jì)準(zhǔn)則應(yīng)該是“一切依賴外部狀態(tài)的數(shù)據(jù)都通過參數(shù)傳入”。這雖然會增加一點(diǎn)數(shù)據(jù)傳輸量但保證了 worker 的純函數(shù)特性也讓整個系統(tǒng)更可控。另一個坑出現(xiàn)在 Windows 環(huán)境。piscina 默認(rèn)使用 worker_threads但 Windows 下文件名路徑分隔符是反斜杠如果直接在filename選項(xiàng)里寫相對路徑很容易出現(xiàn) worker 加載失敗的問題。我的經(jīng)驗(yàn)是始終用path.resolve(__dirname, xxx-worker.js)轉(zhuǎn)成絕對路徑這樣跨平臺基本不會出錯。再有一個容易被忽略的細(xì)節(jié)開發(fā)模式下Vite 的transform鉤子執(zhí)行頻率非常高尤其是編輯文件觸發(fā) HMR 時可能同一秒內(nèi)連續(xù)調(diào)用多次。如果每次調(diào)用都創(chuàng)建一個新 worker 池那性能反而會崩。所以我上面代碼里用了單例模式整個構(gòu)建/開發(fā)生命周期只創(chuàng)建一個 piscina 實(shí)例HMR 觸發(fā)的轉(zhuǎn)換任務(wù)全部復(fù)用同一個池子。3.3 與 esbuild/rollup 的配合哪些任務(wù)真正適合交給 worker用 Worker Threads 加速構(gòu)建時最怕的是“為了用而用”。Vite 本身已經(jīng)集成了 esbuild很多 CPU 密集的轉(zhuǎn)換工作比如 TS 轉(zhuǎn) JS、JSX 編譯已經(jīng)被 esbuild 用 Go 原生代碼并行處理掉了。你再去套一層 worker 來跑這些任務(wù)純粹是多余。根據(jù)我這段時間的實(shí)踐真正適合用 Worker Threads 接管的是這幾類任務(wù)第一是自定義 DSL 轉(zhuǎn)換。如果你的團(tuán)隊(duì)自研了一套模板語法或低代碼配置協(xié)議需要在構(gòu)建期處理成標(biāo)準(zhǔn) JS這通常是純計(jì)算邏輯適合 worker 化。我項(xiàng)目里的自定義模板語法就是這么處理的。第二是復(fù)合 AST 分析。例如在構(gòu)建前掃描所有頁面的依賴關(guān)系、檢查路由覆蓋情況、提取中英文文案鍵值這些任務(wù)單次執(zhí)行毫秒級但全量掃描后累計(jì)耗時可能到幾秒而且邏輯獨(dú)立非常適合切片并行。第三是大型 JSON/代碼生成。比如從接口定義自動生成 TypeScript 類型文件、生成路由配置表這些任務(wù)輸入輸出都很明確并且通常只跟少數(shù)幾個文件相關(guān)不會產(chǎn)生復(fù)雜的模塊依賴。不適合 worker 化的是哪些呢比如簡單的字符串替換、單個文件的小尺寸轉(zhuǎn)換、或者和 Rollup 模塊圖有強(qiáng)關(guān)聯(lián)的邏輯比如需要訪問this.getModuleInfo()的插件鉤子。這些任務(wù)放進(jìn) worker 反而會引入序列化開銷得不償失。4. 實(shí)測對比構(gòu)建時間到底能省多少4.1 測試環(huán)境和方法要驗(yàn)證收益光靠“感覺變快了”是不夠的得有相對可重復(fù)的測試方法。我用的測試項(xiàng)目是一個 Vue 3 TypeScript 的中后臺系統(tǒng)規(guī)模大概是業(yè)務(wù)組件 800 多個、頁面路由 160 多條、依賴包 200 多個dist 輸出產(chǎn)物大小約 8.6MB。測試機(jī)器的配置是 Apple M1 Pro10 核和一臺 Windows 臺式機(jī)AMD Ryzen 7 5800X8 核 16 線程。為了讓數(shù)據(jù)更可信我采取的方法是連續(xù)構(gòu)建 5 次去掉最高和最低值取中間 3 次的平均值。同時記錄兩個維度總構(gòu)建耗時和構(gòu)建過程峰值內(nèi)存。測試分三組第一組是原版 Vite 配置作為基線第二組是僅啟用自定義插件但 worker 數(shù)量設(shè)為 1第三組是啟用 Worker Threadsworker 數(shù)量設(shè)為availableParallelism() - 1。第三組才算是真正驗(yàn)證多線程效果。4.2 數(shù)據(jù)結(jié)果與解讀先看 Windows 臺式機(jī)上的數(shù)據(jù)場景構(gòu)建耗時秒峰值內(nèi)存MBCPU 平均占用基線無 Worker112.6124822%Worker1104.3129026%Worker746.8151268%M1 Pro 上的趨勢類似但絕對值更小基線約 78 秒Worker7 時約 35 秒大約縮短了 55%。這里有一個數(shù)據(jù)很有意思worker 數(shù)量從 1 提升到 7構(gòu)建時間并不是線性遞減——從 104 秒降到了 47 秒提升接近 55%但并沒有到 7 倍。這很正常因?yàn)檎麄€構(gòu)建鏈路里只有一部分任務(wù)被并行化了Amdahl 定律的作用剩下串行部分的時間就在那里再怎么并行也消不掉。內(nèi)存升高的原因也值得說清楚每個 worker 都會創(chuàng)建一個獨(dú)立的 V8 堆而我們的 transform 任務(wù)需要讀取源文件內(nèi)容這些字符串被復(fù)制到 worker 堆里執(zhí)行轉(zhuǎn)換再復(fù)制回來。7 個 worker 并發(fā)執(zhí)行內(nèi)存峰值比基線高 20% 左右但都在可接受范圍內(nèi)。如果你的項(xiàng)目已經(jīng)非常接近內(nèi)存上限建議稍微調(diào)低 worker 數(shù)量。4.3 收益邊界與線程爆炸風(fēng)險Worker Threads 并不是萬能的數(shù)據(jù)也告訴我們收益有邊界。當(dāng)項(xiàng)目規(guī)模小到構(gòu)建總時長只有 15~20 秒時引入 Worker Threads 后改善幅度很小甚至可能因?yàn)榫€程池創(chuàng)建和銷毀的固定成本讓構(gòu)建時間不降反升。我在另一個輕量工具項(xiàng)目上測試基線 9.8 秒加完 Worker 之后變成了 11.2 秒直接勸退。線程爆炸是另一個隱性風(fēng)險。如果你在transform鉤子里不加控制地new Piscina()或者不檢查是否已存在實(shí)例那么 HMR 一次觸發(fā)多個模塊變更時可能瞬間創(chuàng)建幾十個 worker直接把內(nèi)存打爆。這是我在開發(fā)環(huán)境踩過一次的坑。為了避免這個問題我在插件實(shí)現(xiàn)里做了一個簡單加固用piscina null作為實(shí)例是否創(chuàng)建過的判斷并且加了configResolved和closeBundle兩個生命周期鉤子來管理資源。closeBundle里必須await piscina.destroy()否則開發(fā)模式反復(fù)重啟時舊 worker 不會釋放占用的內(nèi)存越積越多。5. 常見問題與排查技巧5.1 報錯與解決速查表多線程方案落地后我整理了幾個高頻問題給它們做成了速查表問題現(xiàn)象可能原因解決方法Worker 加載失敗報Cannot find modulefilename 使用相對路徑Windows 下路徑解析異常使用path.resolve(__dirname, ...)轉(zhuǎn)為絕對路徑構(gòu)建后產(chǎn)物代碼順序錯亂多個 worker 任務(wù)完成后 Promise 未按提交順序 resolve確保使用 piscina 等帶隊(duì)列調(diào)度的庫并按模塊 id 獨(dú)立處理內(nèi)存持續(xù)增長最終 OOM線程池未銷毀或任務(wù)傳遞的數(shù)據(jù)結(jié)構(gòu)過大在closeBundle中銷毀池子壓縮傳遞數(shù)據(jù)大小HMR 更新卡頓每次 HMR 觸發(fā)都創(chuàng)建新 worker 池采用單例模式復(fù)用線程池Worker 中訪問process.env拿到 undefined環(huán)境變量未顯式傳遞或構(gòu)建平臺沒注入將需要的變量通過pool.run參數(shù)傳入 worker構(gòu)建時 CPU 占用 100%進(jìn)程卡死worker 數(shù)量設(shè)置過多上下文切換開銷過大使用os.availableParallelism() - 1設(shè)置線程數(shù)postMessage數(shù)據(jù)序列化報 DataCloneError代碼或數(shù)據(jù)里包含函數(shù)、類實(shí)例等不可克隆對象確保傳給 worker 的數(shù)據(jù)全部是純 JSON 結(jié)構(gòu)5.2 兩個實(shí)在的調(diào)試建議排查多線程問題時最痛苦的是錯誤信息被吞掉。在主線程里跑邏輯時throw new Error()會直接把堆棧打在終端上但 worker 里拋出的異常經(jīng)過 piscina 轉(zhuǎn)發(fā)后堆棧信息經(jīng)常指向 worker 文件內(nèi)部跟業(yè)務(wù)代碼對不上。我的調(diào)試方法是在 worker 入口處包一層try...catch并手動console.error打印錯誤詳情同時把workerData比如當(dāng)前處理的文件 id也一并打出來方便定位是哪個文件觸發(fā)的。第二個建議是給 pool 調(diào)用加一層日志開關(guān)。在插件里通過configResolved讀取process.env.DEBUG_WORKER_POOL如果打開了就在每次任務(wù)完成時打印耗時和 worker 占用情況。這一步在調(diào)優(yōu) worker 數(shù)量時特別有用能直觀看到每個 worker 的負(fù)載是否均衡。如果發(fā)現(xiàn)某些 worker 長時間空閑說明任務(wù)分配可能不均勻需要考慮調(diào)整切片粒度。5.3 關(guān)于開發(fā)模式 HMR 的一個特殊注意點(diǎn)最后補(bǔ)充一個很多人會忽略的細(xì)節(jié)就是開發(fā)模式下 HMR 和 Worker Threads 的交互。Vite 開發(fā)服務(wù)默認(rèn)會監(jiān)聽文件變化并觸發(fā) HMR而 HMR 的transform調(diào)用頻率遠(yuǎn)高于生產(chǎn)構(gòu)建并且每次單文件變更都需要快速返回結(jié)果。如果你在 worker 里跑了比較重的計(jì)算HMR 的響應(yīng)時間可能會變長甚至出現(xiàn)“改一行代碼等兩秒”的情況。這時候優(yōu)化思路不是砍掉 worker而是引入增量緩存在 worker 里維護(hù)一個以文件 id 為 key 的 Map當(dāng)文件內(nèi)容沒有變化時直接返回上次結(jié)果。我的實(shí)現(xiàn)思路其實(shí)很簡單把文件的mtime和內(nèi)容哈希一并傳入 workerworker 內(nèi)部判斷緩存是否命中即可。這樣既保留了生產(chǎn)構(gòu)建的多線程加速收益又不會拖累開發(fā)調(diào)試體驗(yàn)?，F(xiàn)在這個插件已經(jīng)穩(wěn)定跑了兩個多月期間沒有接到過構(gòu)建超時或者內(nèi)存溢出的反饋整體收益還是相當(dāng)讓我滿意的。如果下一步還想繼續(xù)挖可以往兩個方向延伸一是把壓縮階段也交給獨(dú)立的 worker 池處理和 transform 階段的池子隔離避免互相等待二是用 SharedArrayBuffer 做線程間的共享緩存進(jìn)一步減少數(shù)據(jù)拷貝開銷。等這兩個方向有穩(wěn)定結(jié)果了我再寫一篇新的實(shí)踐記錄。