Skip to main content
Extension.js 與 WXT 都是用來打造跨瀏覽器擴充功能的現代框架。兩者在目標上重疊,但在理念上有所差異。本頁提供事實層面的比較,幫助你依專案需求做出選擇,而不是被行銷話術左右。

​
TL;DR:該選哪一個?

選擇 Extension.js,如果你…

  • 想把 manifest.json 當作唯一來源,而不是由設定產生。
  • 喜歡貼近原生 WebExtension 模型(實體檔案、透明輸出)。
  • 想用一行指令開發遠端範例:extension dev <github-url>。
  • 想要 Rspack 的 Rust 等級建置速度,以及一流的 AI/MCP 工具。

選擇 WXT,如果你…

  • 偏好檔案系統慣例(entrypoints/)勝於明確的 manifest。
  • 需要把 Manifest V2 作為主要目標。
  • 希望各處預設都使用自動 polyfill 過的 browser.* 命名空間。
本頁其餘內容會逐個維度佐證上面的摘要。

​
一覽表

​
思維模型

Extension.js 貼近平台。 你撰寫 manifest.json 並參考實體檔案。CLI 會編譯、依瀏覽器過濾、再輸出。如果你已經了解擴充功能的結構,這個框架不會擋你的路。 WXT 把平台抽象化。 進入點是從目錄結構推導出來(entrypoints/popup/、entrypoints/content.ts),而 manifest 則由你的設定與原始碼產生。如果你偏好慣例優於設定,WXT 為每個你寫的檔案做得更多。 兩種方式並沒有絕對的優劣。選擇取決於你想看見你的 manifest,還是宣告你的 manifest。

​
CLI 介面

​
Extension.js

引數也可以是遠端 GitHub URL 或 ZIP 壓縮檔,適合在不 clone 的情況下啟動範例。詳見立即開始。

​
WXT

WXT 將 dev/build/zip 拆分為不同指令。Extension.js 則把封裝整合進 build --zip。

​
跨瀏覽器策略

兩個框架都用單一程式碼基底輸出多個瀏覽器,但機制不同:
  • Extension.js 在一份 manifest.json 內使用瀏覽器前綴 manifest 欄位(chrome:、firefox:、gecko: 等)。未加前綴的鍵套用到所有目標;加了前綴的鍵只會落到對應的建置。
  • WXT 從 wxt.config.ts 與每個目標的覆寫運算 manifest。瀏覽器差異存在於 TypeScript 設定中,而不是 manifest 本身。
如果你的團隊中有設計師或 PM 會閱讀 manifest.json,前綴鍵可以讓那份檔案維持為唯一來源。如果你的團隊希望擴充功能設定與其他 TypeScript 設定放在一起,WXT 的做法讀起來會更自然。

​
遷移路徑

如果你目前在使用 WXT,並打算評估 Extension.js,典型的遷移工作會涉及三件事:
  1. 將 entrypoints/ 內容搬回扁平檔案,並從手寫的 manifest.json 參考它們。
  2. 用 extension.config.js 取代 wxt.config.ts 來設定建置預設值。
  3. 用 extension dev/extension build 取代 wxt/wxt build 腳本。
大多數 React、Vue 與 Svelte 原始檔可以直接複製過來,毋需修改。

​
何時選擇 Extension.js

  • 你想把 manifest 當作唯一來源,而不是由設定產生。
  • 你想要一個 CLI 引數就能開發遠端範例(extension dev <github-url>)。
  • 你希望文件擁有一流託管 MCP 的 AI 工具支援。
  • 你希望大型擴充功能享有 Rspack 的 Rust 級編譯速度。

​
何時選擇 WXT

  • 你偏好檔案系統慣例勝於明確的 manifest。
  • 你需要把 Manifest V2 當作主要目標。
  • 你希望各處預設都使用自動 polyfill 過的 browser.*。

​
延伸閱讀