为什么选择 Manifest V3

3-1 一句关于旧标准的话

Manifest V2 已于 2026-08-31 退出 Chrome Web Store（Chrome 网上应用店），彻底成为历史。这件事只此一句，后面不再提旧写法，也不做任何新旧对照。

你只要知道：今天能上架、能运行、值得学的是 Manifest V3。从这一章往后，本教程所有示例都建立在 MV3 之上。

3-2 本教程唯一的准绳就是 MV3

为什么死磕 MV3，而不是兼容一堆旧写法？原因很实在。

浏览器只收 MV3。Chrome、Edge 商店都只接受 MV3 的包，写旧标准等于写了个发不出去的东西。

旧标准最被人诟病的几个毛病——后台常驻吃内存、能远程拉代码不安全、网络拦截太重——MV3 一并解决。新能力也几乎都只给 MV3，比如侧边栏、scripting 注入、Promise 化接口。

所以本教程从头到尾只讲 MV3。你学的每一行，都是现在就能用的真东西。下面把 MV3 相对旧时代最关键的四个变化讲透。

3-3 特征一：服务工作者替代常驻后台

旧标准的后台是个”常驻页面”，扩展一装，它就一直住在内存里，哪怕你什么都不干。很多扩展后台很闲，却照样占着资源，电脑因此变卡、耗电变快。

MV3 把后台换成了服务工作者（Service Worker）。它只在有事时才被唤醒，处理完事件立刻休眠。需要定时任务，用 alarms 接口来叫醒它，而不是自己在后台死循环。

举个例子：你想每隔一小时检查一次邮件。旧写法是在后台开一个 setInterval 死循环，永远占着内存；新写法是用 alarms 创建一个定时任务，到点唤醒服务工作者跑一次，跑完又睡。差距就在这一睡一醒之间。

3-4 特征二：禁止远程托管代码

MV3 明文规定，扩展里运行的 JavaScript 必须打进包里，不允许运行时从远程网址拉一段代码来执行。这就是”禁止远程托管代码”规则。

这条规则看起来麻烦，其实是好事。过去有坏扩展偷偷从服务器下载恶意脚本，用户完全不知情。现在所有代码都经过商店审核，你装到的就是审核过的那一份，没人能中途偷换。

3-5 特征三：declarativeNetRequest 接管网络

修改网络请求这件事，在旧标准里靠一个叫 webRequest 的接口，而且是阻塞式——请求必须等扩展逐条检查完才能放行，浏览器因此变慢。

MV3 改用 declarativeNetRequest。它靠”规则”工作：你提前声明一组规则，浏览器自己高效地匹配和执行，不需要扩展在每条请求上卡一下。性能更好，也更保护隐私，因为扩展不必读取请求内容就能拦。

举个生活化的比喻：旧方式像每次出门都要保安逐个盘问访客；新方式像门口先贴好规则，保安按规则自动放行，不用每次都把你叫住。规则提前定好，执行交给浏览器，又快又省心。

3-6 特征四：Promise 化与新增 API

MV3 让更多接口支持 Promise。过去调接口要传回调函数，层层嵌套容易写出”回调地狱”；现在可以用 await 把异步写得像同步一样清爽。

同时 MV3 引入了一批新能力：action 统一管理工具栏按钮、scripting 推荐用来注入脚本、sidePanel 开侧边栏。这些在旧标准里要么没有，要么写法更绕。

3-7 MV3 带来的现实影响

把四点合起来看，MV3 不只动了技术，也动了生态。对开发者，后台写法、网络写法都要换思路，审核也更严。对用户，扩展更省资源、更安全，电脑更稳。

也许你会觉得限制变多了。但换个角度，这些限制逼着大家写出更干净、更可信的扩展。长远看，对整个扩展生态都是好事。

举两个直观的例子。过去有的扩展后台常驻，开着浏览器就一直吃内存，电脑风扇呼呼转；换成服务工作者后，它只在需要时醒来，平时几乎零占用。再比如过去有扩展运行时从远程拉脚本，服务器被黑就可能危害百万用户；现在代码全部打包审核，这种风险被直接堵死。

四句话收个尾：后台变轻、代码打包、网络声明式、接口现代化。这就是 MV3 的骨架。下一章我们动手把开发环境搭起来，你马上就能写代码了。