横向对比：WXT 与其他方案

对手是谁

写浏览器扩展，常见四条路线：原生开发（手写 manifest + 自己搭构建）、Plasmo（框架）、CRXJS（Vite 插件）、WXT（框架）。官方文档用一张对比表横评了 WXT、Plasmo、CRXJS 三家，本节把它翻译成中文并逐项解读。

基础能力对比

图例：✅ 完整支持，🟡 部分支持，❌ 不支持。

能力	WXT	Plasmo	CRXJS
持续维护	✅	🟡 近维护模式	🟡 存疑
支持全部浏览器	✅	✅	🟡 v2 稳定版未发布
支持 MV2	✅	✅	🟡 二选一
支持 MV3	✅	✅	🟡 二选一
生成商店 zip	✅	✅	❌
生成 Firefox 源码包	✅	❌	❌
一流的 TypeScript 支持	✅	✅	✅
按文件发现入口点	✅	✅	❌
入口点内联配置	✅	✅	❌ 全在 manifest 里
自动导入	✅	❌	❌
可复用模块系统	✅	❌	❌
支持全部前端框架	✅	🟡 仅 React/Vue/Svelte	✅
框架专属入口（如 Popup.tsx）	🟡 仅 html/ts/tsx	✅ 含 vue/svelte	❌
自动化商店发布	✅	✅	❌
未注册 HTML 页	✅	✅	✅
未列出脚本	✅	❌	❌
ESM 内容脚本	❌ 开发中	❌	✅

解读三点。其一，CRXJS 本质是 Vite 插件，入口点配置全在 manifest 里，这决定了它「单清单、少约定」的形态；ESM 内容脚本是它的独门功夫，但代价是不支持 MV2/MV3 同时输出。其二，WXT 与 Plasmo 都是框架，按文件发现入口点、内联配置是共同基因，差别在生态层：自动导入、模块系统、Firefox 源码包、未列出脚本这些是 WXT 独有。其三，Plasmo 目前维护节奏放缓，选型时要考虑长期风险。

开发体验对比

能力	WXT	Plasmo	CRXJS
支持 .env 文件	✅	✅	✅
自动开浏览器并装好扩展	✅	❌	❌
UI 热更新	✅	🟡 仅 React	✅
HTML 改动自动刷新	✅	🟡 整扩展重载	✅
内容脚本改动自动刷新	✅	🟡 整扩展重载	✅
后台改动自动刷新	🟡 整扩展重载	🟡 整扩展重载	🟡 整扩展重载
遵守内容脚本 run_at	✅	✅	❌ 异步加载

「自动开浏览器并装好扩展」是 WXT 开发体验里最省事的一环：wxt dev 起来，浏览器自己开好、扩展自己装上，改完代码热更新。Plasmo 与 CRXJS 需要手动刷新或用别的工具。整扩展重载不是缺点，是浏览器扩展的普遍约束——后台脚本重载必然影响整个扩展，三家都一样。

内置封装对比

能力	WXT	Plasmo	CRXJS
Storage 封装	✅	✅	❌
Messaging 封装	❌ 官方推荐 @webext-core	✅	❌
内容脚本 UI 封装	✅	✅	❌
I18n 封装	✅	❌	❌

这里有个容易误读的点：官方表里 WXT 的 Messaging 是 ❌。不是说 WXT 不能用消息通信，而是它没有内置消息封装，推荐用社区包 @webext-core/messaging 补上类型安全（§17 整章都在讲这个组合）。CRXJS 的 ❌ 同理——「没有内置封装」不等于「做不到」，用 chrome/browser 原生 API 或第三方包即可。

按场景选型

• 从零开始、想要省心：WXT。自动开浏览器、热更新、类型安全、一条命令上架，这些开箱即得。
• 已是 Vite 项目、只想加扩展：CRXJS 或 WXT 都行。CRXJS 改动最小，但注意它 MV2/MV3 二选一；WXT 的迁移路径见 §44。
• 重度依赖 ESM 内容脚本：CRXJS 目前是唯一选择，WXT 的 ESM 内容脚本还在开发中（跟踪 wxt-dev/wxt#357）。
• 要用 Vue/Svelte 写入口文件：Plasmo 的框架专属入口支持最全（.vue/.svelte 直接当入口），WXT 需要一层 html 壳。
• 已有扩展要搬家：先看 §44 的迁移路径，再决定。

没有银弹。框架解决「约定与自动化」，插件解决「融入现有工程」，原生解决「零依赖」。清楚自己卡在哪一环，选型就完成了一半。

小结

• 三张表横向对比 WXT / Plasmo / CRXJS 的基础能力、开发体验与内置封装。
• 没有银弹：框架解决「约定与自动化」，插件解决「融入现有工程」，原生解决「零依赖」。
• 各项目维护状态会变，选型前查一下最新情况。