BrowserDevTools

Vite 外掛，依場景分類

Vite 外掛有數千個，而「哪個最好」是錯的問題——有用的問法是「哪個適合這件工作，代價是什麼」。六個場景、真的仍在維護的那些外掛，以及讓每一個都變成取捨的但書。

一個 Vite 外掛就是一個建置期相依套件，供應鏈重量和任何其他相依套件一樣：它會在每一次建置、每一台機器、CI 上執行。所以這個頁面不排名。它照你想完成的工作分組，指名一兩個仍在維護的選擇，並講出多數文章略過的但書——因為但書通常才是決定的那部分。

底下每一個都是你安裝進自己儲存庫的專案；本站自己託管的，只有它自己建置的 Vite 工具。這些連結沒有任何一個是付費的，背後也都沒有聯盟行銷的安排。

場景 01

PWA 與離線

你想要什麼: 一個可以安裝、在沒有網路時仍然打得開的應用程式。

套件它做什麼但書
vite-plugin-pwa底層是 Workbox：一份設定就能產生 web manifest 與一個 service worker，具備預先快取與執行期快取策略。外掛本身很簡單，快取策略不是。一條錯的執行期規則可以連續好幾天送出過期的 HTML。先從 generateSW 開始，等到真的需要自訂路由時再換成 injectManifest。
@vite-pwa/assets-generator在建置時從一張來源圖產生整組圖示——包含 maskable 圖示。產生的圖示還是要有人看過：檢查 16 px 的 favicon 與 maskable 安全區，這正是我們的圖示產生器存在的理由。

我們的看法: 等到有具體的離線需求時再加 PWA 支援；一個你沒測試過的 service worker，就是一個等著在下次部署時爆發的快取 bug。

場景 02

圖片最佳化

你想要什麼: 更小的圖片，而且不必手動匯出每一種尺寸。

套件它做什麼但書
vite-imagetools在 import 圖片時帶上查詢參數（width、format、quality），建置時就會輸出重新調整尺寸、重新編碼的各種變體。它相依於 sharp，一個原生二進位檔——CI 的映像檔必須裝得起來。而且只有在你真的送出 <img srcset> 時才划算；調整了尺寸卻沒用到那些變體，純粹只是建置成本。
vite-plugin-image-optimizer對 Vite 已經輸出好的資源跑 sharp／svgo，在不改動你 import 程式碼的情況下減少位元組。它在每一次建置都會執行，所以省下的量要量測：我們的打包產物分析器會回報每個資源的前後大小。

我們的看法: 圖片的位元組通常主宰一個頁面，所以這是少數取捨很容易說得通的外掛類別——但要量測，不要用猜的。

場景 03

SSR、SSG 與預先算繪

你想要什麼: 送達時就已經算繪好的 HTML，為了 SEO 或首次繪製的速度。

套件它做什麼但書
vike建立在 Vite 上的檔案式 SSR 框架（前身是 vite-plugin-ssr）：路由、資料載入與伺服器端算繪，不必採用一整套 meta-framework。SSR 是一種應用程式架構，不是一個勾選框：你從此有了一台伺服器、hydration 不一致的問題，以及兩個環境要推理。如果你只需要靜態 HTML，改用 SSG。
vite-ssg在建置時把你的 Vue 應用程式預先算繪成靜態 HTML。它只預先算繪你列舉出來的路由。任何動態的東西仍然需要一台伺服器或客戶端的 fetch，而天真的「我們加了 SSG」說法，正是在那裡破功。

我們的看法: 在 SSR 與預先算繪之間做選擇之前，先確定你的問題是哪一個——搜尋能見度還是首次繪製；它們各自解決其中一半。

場景 04

打包分析

你想要什麼: 看清楚建置產物裡到底有什麼。

套件它做什麼但書
rollup-plugin-visualizer輸出打包產物的互動式 treemap，讓你看見某個 chunk 是哪個模組造成的。它給的是圖，不是判定：它不會告訴你 220 KB 的 JavaScript 可不可以接受，而且它要你把建置產物交給它。至於預算的問題，我們自己的分析器在本機讀取資料夾，再拿你設定的上限來比對。

我們的看法: 用視覺化工具找出元凶，再用預算工具判定它在不在意——並把預算數字留在儲存庫裡，讓它們撐過下一次重構。

場景 05

開發體驗

你想要什麼: 每個元件檔裡少一點樣板程式碼。

套件它做什麼但書
unplugin-vue-components元件在被使用時自動 import，包含由 resolver 驅動的 UI 套件，讓你不用再寫 import 那一行。魔法般的自動 import 會藏住一個名字的來源——對不是你寫的設計系統來說沒問題，對你自己的元件就沒那麼好，因為在那裡，一行明確的 import 就是文件。
unplugin-auto-import自動 import 像是 ref 與 computed 這類 API，並寫出它們需要的型別宣告。把產生的 .d.ts 提交進版控，否則你的編輯器與 CI 對「什麼存在」會有不同看法。它也會讓一個漏掉的 import 看起來像執行期的謎團，而不是編譯錯誤。

我們的看法: 這兩個是最受歡迎、也最容易回頭的：先採用一個，跟它相處一個 sprint，只有在 diff 變得更安靜時才留下它。

場景 06

舊版瀏覽器與傳輸大小

你想要什麼: 支援某個較舊的瀏覽器，或為伺服器預先壓縮。

套件它做什麼但書
@vitejs/plugin-legacy額外輸出一個舊版打包產物，內含舊瀏覽器需要的 polyfill，透過 nomodule 回退機制送達。它會讓輸出大約變成兩倍，並拉進 terser。針對你的 analytics 真的顯示的瀏覽器建置——支援 IE 時代的瀏覽器，會讓每一位現代訪客都付出一點代價。
vite-plugin-compression在建置時把資源預先壓縮成 .gz 或 .br，給直接送出預壓縮檔的主機用。如果你的主機即時壓縮（Vercel 與 Netlify 都會），它就沒用，而且會讓部署裡的檔案變多。加進來之前，先確認你的平台已經做了什麼。

我們的看法: 這兩個都是「我們負擔得起嗎？」的答案——所以用資料回答：你 analytics 裡的瀏覽器，以及一次真實建置的傳輸大小。

檢查一次改動的結果

上面每一個外掛都會改動你的設定或打包產物，而我們自己的 Vite 工具正是為了這兩個時刻存在：它們在瀏覽器裡執行，所以你可以在一個還沒推到任何地方的建置上使用它們。

Vite 設定檔產生器

勾選專案需要的項目，就能拿到一份乾淨的 vite.config.ts——別名、含改寫與 ws 的開發代理、建置目標、manual chunk——外加安裝指令。

程式碼產生

Vite 設定健檢

貼上 vite.config.ts 與 package.json：被 import 了卻從未安裝的外掛、沒有用 JSON.stringify 包成字串的 define 值、空的 envPrefix、es5 目標——在建置跑起來之前就找出來。

程式碼產生

打包產物預算分析器

拖入你的 dist 資料夾：每個 chunk 的體積、真實 gzip、進入點與延遲載入的區分，以及哪個 chunk 超出預算——完全不必上傳你的建置產物。

程式碼產生

Vite .env 檢查器

把 .env 與 .env.example 比對：缺少、多餘、空值、重複鍵，以及你不小心暴露給客戶端的密鑰。

資料與設定

關於連結與金錢

這裡點名的套件背後沒有任何聯盟行銷關係，也沒有賣出任何排名——本站的經費來自展示型廣告，而它的 /advertising 頁面承諾的正是這件事。如果某個推薦是錯的，儲存庫才是事實來源，套件’s changelog 也是。

常見問題

要怎麼判斷一個外掛是否仍在維護？
三個訊號：最後一次發布的日期、它是否支援目前的 Vite 主版本（peerDependencies 通常寫得很明確），以及它有沒有官方對應方案。一個跨過兩個 Vite 主版本都沒更新過的外掛，不管有幾顆星，都是個負擔。
這些可以一起用嗎？
實務上可以，但不一定照你安裝的順序：legacy 與 compression 都會動到輸出檔案，圖片工具會掛進資源處理流程，而 DX 外掛會改寫 import。一次加一個，每加一個就看一次建置輸出，並跑一次設定健檢，這樣就不會漏掉某個沒被寫進 package.json 的項目。
我要去哪裡找這裡沒列出的外掛？
awesome-vite 清單是社群索引，而用「vite-plugin」關鍵字搜 npm 的效果好得出乎意料。安裝任何東西之前，先看看 Vite’s 外掛 API：出乎意料多數的「外掛」需求，其實只是設定裡的十五行程式，而本機函式沒有供應鏈。
這些裡面，你們自己在這個網站用了哪些？
本站是 Astro 加 Vue 島，所以外掛面積很小：框架外掛加一次靜態建置。這也是這裡的工具都與框架無關的原因——它們是為你的建置而做，不是為我們的。
這些推薦是付費的嗎？
不是。這個頁面上沒有聯盟連結，也沒有贊助版位；套件被點名，是因為它們是在真實專案裡會出現的那些。請自己確認——像這樣一個頁面給的推薦是起點，不是保證。

BrowserDevTools