浏览器扩展开发工程：Manifest V3、权限模型与跨浏览器发布（横纵综合报告） 未开始

题记与说明

• 课题：《浏览器扩展开发工程：Manifest V3、权限模型与跨浏览器发布》
• 补充课题：个人效率扩展从零到上架的最小路径
• 成文日期：2026-11-06
• 输入材料：本报告由同日完成的两份章节文件综合而成——纵轴《浏览器扩展开发工程：Manifest V3、权限模型与跨浏览器发布——纵轴发展史》与横轴《浏览器扩展开发工程（Manifest V3、权限模型与跨浏览器发布）——横向对比报告》。两章均基于当日实际执行的网络检索与网页读取，关键事实附来源 URL。
• 终稿说明：本文件为按独立审读意见（共 8 条）逐条修订后的最终稿；初稿保留于 drafts/ 目录未改动，逐条修订记录见文末附录。市场份额、框架评测结论、activeTab/scripting 权限语义等被质疑点，在终稿修订时重新实际抓取来源核验（详见附录与参考来源标注）。
• 综合勘误（本次综合时核验并修正的三处两章分歧）：
  1. WWDC23 会话链接：横轴引用的 wwdc2023/10179 经本次直接抓取实为 "What's new in Core Motion" 会话；正确链接为纵轴所引 wwdc2023/10119（"What's new in Safari extensions"），本次已抓取两页逐一核验，全文统一采用 10119。
  2. 市场份额：横轴引用的份额（Chrome ≈68.8%、Safari ≈16.6%、Edge ≈5.3–5.4%、Firefox ≈2.6%）标注为"2026-10 全球份额"，但该口径与 Statcounter 页面当前显示的月度表对不上——终稿修订时（2026-11-06）再次直接抓取 Statcounter，页面表头明确显示 September 2026 月度数据：Chrome 66.36%、Safari 18.27%、Edge 6.04%、Firefox 2.8%。两处数字是同一波动数据源在两个不同抓取时点/视图上的读数，不构成"用新数据替换过时数据"的关系（2026-10 月度份额口径在当前页面上无法复现，可能对应图表中 10 月的当月/滚动视图）；本文统一采用与页面当前表头一致的 2026-09 月度值，并提示读者使用时以 Statcounter 最新月为准（详见 3.3）。
  3. Safari 的 DNR 能力：横轴" Safari 连 redirect 动作都不支持"的说法与纵轴所引 WWDC23 会话原文冲突。按官方会话记录（本次已抓取全文）：Safari 15 引入 DNR，16.4 起支持修改请求头与 redirect 动作，但须声明 declarativeNetRequestWithHostAccess 权限且按站点获得用户授权；阻塞式 webRequest 则始终不支持。本文以官方会话为准，W3C issue #694 作为生态讨论背景保留。

TL;DR

浏览器扩展二十年主线是危机驱动收权：脚本漏洞与广告注入危机催生商店、清单、权限三件套；WebExtensions 让"一次开发、四家上架"成真；Manifest V3 以按需后台、声明式拦截与最小权限重写规则，2026 年 8 月底 Chrome 商店（CWS）清空全部 MV2。当前格局：Chromium 系 MV3 一统、Firefox 双轨保留阻塞拦截、Safari 走封闭分发。对个人效率扩展：先以 bookmarklet（书签脚本）/用户脚本验证想法，确需扩展时用最小权限（activeTab＋storage＋scripting，站点权限按需申请）在 Chrome 首发，再免费增量上 Firefox/Edge 商店；就 CWS 而言权限越宽、审核越慢且被拒概率越高（Firefox 的审核时长波动则主要来自人工复审排队，见 3.2）。

一、纵轴：发展脉络（2004–2026）

扩展平台今天的每一根支柱——商店、清单文件、权限弹窗、跨浏览器兼容层——都不是设计出来的，而是被二十年间的危机一次次逼出来的。按时间划分六个阶段。

1.1 阶段一（2004–2008）：用户脚本与 XUL——扩展的两种原型

2004 年 11 月 28 日 Aaron Boodman 启动 Greasemonkey，12 月 6 日发布首版——这是浏览器史上第一个让普通用户安装脚本改写网页的扩展（Wikipedia: Greasemonkey）。2005 年 5 月《连线》报道时已有约 60 个通用脚本和 115 个站点专用脚本流通；同年 7 月 Mark Pilgrim 发现脚本可越权读写的严重漏洞并在 3.5 版修复——扩展安全模型的第一次警示。2005 年底社区建立脚本仓库 userscripts.org，该站 2010 年进入维护模式、2014 年 8 月关停，继任者 Greasy Fork 与 OpenUserJS.org 延续至今。同期 Firefox 原生扩展走的是另一条更重的路线：基于 XUL/XPCOM 深度改写浏览器界面与内部组件，能力极强但完全绑定 Firefox，每次内核重构都要大规模适配（How-To Geek, 2015）。（更早的 IE 时代通过浏览器助手对象 BHO 做扩展、权限完全不受限，是"无权限模型"的反面教材——此为背景性既有常识，本次未单独检索验证。）

这一阶段的两个未解问题——任意代码注入等于巨大安全面、分发没有官方渠道——直接催生了后来"商店＋清单＋权限声明"的三件套。

1.2 阶段二（2008–2012）：Chrome 三件套定型

2009 年 12 月 8 日 Google 宣布扩展功能登陆 Chrome Windows beta，上线即有 300 多个扩展并配套 gallery 分发渠道（Chromium Blog, 2009-12-08）；2010 年 5 月 I/O 预览、12 月 7 日 Chrome Web Store 正式开放（Wikipedia: Chrome Web Store）。Chrome 扩展模型的关键决策是把扩展定义为"受限的网页"：manifest 声明权限、独立进程运行、UI 用纯 Web 技术——与 XUL 深绑内核的路线形成鲜明对照。版本制度上，manifest version 1 在 Chrome 18 被标记弃用，Chrome 23（2012 年 11 月）起强制 manifest_version: 2（Chrome for Developers）——"清单文件本身就是版本化 API 契约"自此成为惯例。

此阶段确立了此后十五年的基本形态：商店统一分发（含自动更新）、manifest 版本化、权限安装时一次性弹窗声明。注意此时权限模型仍是"一次性全给"——用户要么接受全部权限，要么不装；这一妥协将在阶段三被清算。

1.3 阶段三（2012–2018）：恶意扩展逼出权限收紧

这五年 Chrome 生态屡次爆发恶意扩展事件。标志性研究是 Google 团队 2015 年 5 月发表的《Ad Injection at Scale》（IEEE S&P 2015，Kurt Thomas 等）：广告注入影响 Google 超过 5% 的日独立 IP，生态中约 50,000 个扩展与 34,000 个软件程序在注入广告，识别出 3,049 个注入库、约六成使用欺骗性手段（Google Security Blog、论文 PDF）。2015 年前后 Google 连续清理广告注入器、移除高危 API、收紧审核；2018 年 10 月发布"Trustworthy Chrome Extensions, by default"计划——移除站内内联安装、限制远程托管代码、要求权限使用说明——被后续报道明确追溯为 Manifest V3 的前奏（The Register, 2020-12-10）。

驱动逻辑：经济利益驱动的注入产业链证明"安装时一次性授权"已经失守——扩展一旦获得宽权限，用户再无感知。平台被迫把安全从"事前一次性审查"改为结构性约束，让危险的 API 模式从架构上难以存在。optional_permissions、运行时请求、按站点授权等机制都是这条防线的产物，也是本课题"权限模型"一说的真正起点。

1.4 阶段四（2015–2020）：WebExtensions 的胜利——跨浏览器第一次成真

2015 年 8 月 21 日 Mozilla 官宣 WebExtensions API，明确新 API 将"与 Chrome/Opera 所用模型大体兼容"并最终取代 XUL（Mozilla Add-ons Blog），媒体以"Chrome Extensions Are Coming to Firefox"为题报道，同时引发"Firefox 变成 Chrome 复制品"的批评（TechCrunch、How-To Geek）。2017 年 Firefox 57 "Quantum" 起，WebExtensions 成为 Firefox 唯一支持的扩展类型，旧 XUL 生态一次性清零。Microsoft 方面：2019 年 11 月宣布新 Edge、2020 年 1 月 15 日 Chromium 版正式发布，2019 年 12 月开放扩展提交、2020 年 2 月 Edge Add-ons 商店对开发者开放（The Verge、TNW、TechRadar、ghacks）。Apple 方面：2020 年 WWDC 宣布 Safari 14 支持 WebExtensions API，并提供 xcrun safari-web-extension-converter 把 Chrome/Firefox/Edge 扩展一键转换为带原生 App 壳的 Safari 扩展（Apple Developer、MacRumors）。工具链同期成形：Mozilla 维护 web-ext CLI 与 webextension-polyfill（在 Chrome 补齐 promise 风格 browser.*），2019 年 10 月 web-ext 3.2.0 明确以跨浏览器开发为目标（Mozilla Hacks、GitHub）。

至此"跨浏览器发布"从插件时代的奢望变成工程默认值，开发者第一次可以"写一次、发四家"；代价是 Firefox 自主扩展能力的大幅收缩——这是本课题第一位真正的"产品取舍"。

1.5 阶段五（2018–2024）：Manifest V3 之争——性能、安全与广告拦截的十年拉锯

按时间排列的关键节点：

• 2018 年 10 月：Google 宣布 MV3，核心变更为非持久 service worker 取代常驻后台页、限制远程托管代码、以声明式 declarativeNetRequest（DNR）取代可编程阻塞式 webRequest、收紧 CSP（The Register、官方迁移总览）。
• 2019 年夏：首个支持 MV3 的 Canary 落地，"MV3 将扼杀广告拦截器"争议爆发（ZDNet）。
• 2020 年 12 月：MV3 随 Chrome 88 beta 可用；2021 年 1 月起 CWS 接受 MV3 提交（Chromium Blog）。
• 2021–2022：EFF 持续批评 MV3"损害隐私、安全、创新"（EFF, 2021-12）；CWS 于 2022 年 1 月停收新 MV2 公开/不公开列出扩展、6 月停收新 MV2 私有扩展（官方时间线）；webRequestBlocking 在 MV3 中仅对企业策略安装保留（Chrome for Developers）。
• 2022–2023（Firefox 的差异化答卷）：2022 年 11 月 21 日 Firefox Nightly 开放 MV3 签名，2023 年 1 月 Firefox 109 首次向全体用户支持 MV3。Firefox 的 MV3 用 event page（非持久后台页）而非 service worker，host_permissions 默认按可选权限处理（需运行时 permissions.request()，新增 optional_host_permissions 键），并保留阻塞式 webRequest、同时提供能力增强版 DNR（Extension Workshop 迁移指南、MDN optional_permissions、Mozilla Discourse）。
• 2023 年底：Chrome 120 引入 MV3 下的 userScripts API，为 Tampermonkey 类脚本管理器续命，但限制严格（Chrome for Developers、Tampermonkey #644）。
• Microsoft 立场：2020 年 10 月宣布跟随 MV3 但长期不给禁用阻塞 webRequest 的时间表（The Register），2025 年起跟进 MV2 退场（AdGuard）。

三条驱动线交织：(1) 资源占用——常驻后台页是 Chrome 内存问题重灾区，service worker 按需启停是性能工程；(2) 安全——可编程请求拦截给了扩展"看并改写全部流量"的能力，DNR 把拦截规则从任意代码降格为可静态审计的声明；(3) 权力——拦截能力收窄客观上保护 Google 的广告业务，这是 EFF、uBlock Origin 作者 Raymond Hill 等与 Google 拉锯十年的核心。Firefox 的答卷证明省电省内存可以用不同手段达成，"MV3 ≠ 必须消灭阻塞式 webRequest"由此成为行业共识性批评。

1.6 阶段六（2025–2026 当下）：MV2 清场完成与"后 MV3 时代"的商店治理

MV2 退场全程以 Chrome 官方时间线为准（纵轴成文时已全文读取核验，页面标注最后更新 2026-09-09；两章表述统一如下表，MV2 deprecation timeline）：

用户侧对应物是基于 DNR 的 uBlock Origin Lite，规则上限与动态过滤能力受限（Bumbletap、AdGuard）。Edge 的清退晚一拍：2026 年 8 月起逐步禁用 MV2，预计 2027 年初移除（同 AdGuard）。Firefox 的当下立场：2025 年 2 月 25 日 Mozilla 发文《Mozilla's approach to Manifest V3》，重申同时支持 MV2 与 MV3、不设 MV2 下架时间表，Firefox 因此成为 uBlock Origin 完整版的最后主要阵地（Mozilla Blog）。

商店治理同步收紧：开发者账号强制两步验证（2021 年 6 月宣布，Chrome for Developers）；审核官方口径"多数扩展数天内完成"且不可加急（Review process），社区长期抱怨积压；2025 年 1 月 13 日 Adblock Plus 作者 Wladimir Palant 发表《Chrome Web Store is a mess》系统性指控商店充斥垃圾提交、审核标准不一（palant.info）；自动化发布方面 CWS Publish API v1 已宣布弃用、仅支持到 2026 年 10 月 15 日，CI 上传工具被迫迁移 v2（chrome-webstore-upload #114）。

1.7 纵轴收束：三轮驱动因素，一个不变量

回望 2004→2026，扩展平台被三轮力量反复重塑：安全危机（Greasemonkey 漏洞 → 广告注入产业链 → 恶意扩展泛滥）催生清单、商店与权限声明；性能工程（常驻后台页 → event page / service worker）改变扩展的生命周期心智模型；平台权力与商业模式（DNR 收窄拦截、Firefox 差异化、Safari 封闭分发）决定同一份"MV3"在各家浏览器上的真实含义。不变量只有一条：扩展永远运行在"用户信任＋平台容忍"的夹缝里，工程上的最优解始终是少要权限、少驻内存、可被静态审计——这既是 uBlock Origin Lite 被迫接受的现实，也是个人效率扩展一次过审的诀窍。

二、横轴：横向对比（2026-11 截面）

在 2026-11-06 这个时间截面上，"做一个浏览器扩展"不再是单一命题，而是四组互相独立又互相耦合的选型。

2.1 形态之争：要不要做扩展

同样的"个人效率"诉求至少有五种实现形态：

要点：只有扩展能拿到 tabs、idle、alarms、DNR、原生 messaging 等浏览器级 API——扩展用于"增强浏览体验本身"，PWA/Electron 用于"独立应用"（Stack Overflow）；上表"约八成"的支撑仅为社区经验估计——一条 Reddit 讨论与 Tampermonkey 官网口径，并非严格统计——据此只能说用户脚本大致可覆盖多数个人用例且发布最轻，但普通用户安装门槛高（Reddit、Tampermonkey）；bookmarklet 在桌面与移动端行为一致且零审核，是最低成本跨端注入方案（HN #34830825）；经验法则是扩展适合"围绕当前页面的 1–2 次点击"型交互，需要独立 UI 或持久化的应做全量 Web 应用（Kanopy Labs）。

2.2 上架路径：发到哪里

（份额来源：Statcounter，为波动数据；终稿修订时（2026-11-06）再次抓取，页面表头显示 September 2026 月度表。审核口径：CWS 注册、Edge 优先审核公告、Edge 认证时长讨论、Firefox 审核时长讨论、Apple Safari Extensions、App Review Guidelines。）

• Chrome 是必选项：66% 量级的份额决定了它就是"市场"本身；$5 一次性注册费自 2020 年 3 月起执行（Chromium Blog），加上强制 2FA（政策）。MV2 清场已走完（见 1.6），MV3 是 Chrome 上唯一可发布的形态。
• Edge 是低成本平行分发：免费注册，Chrome 的 MV3 包基本零改动直接复用（Edge MV3 迁移）。
• Firefox 能力最宽松：免费上架，审核从"秒签"到数周人工不等；份额虽缩到 2.8%，却是唯一保留阻塞式 webRequest 的主力内核——"能力型扩展"的不可替代出口。
• Safari 高门槛：扩展不能独立上架，必须用 xcrun safari-web-extension-converter 打包进 macOS/iOS/iPadOS 宿主应用走 App Review（Apple 打包文档、分发文档），并单付 $99/年。值得注意的细节（WWDC23 会话原文，本次已抓取核验）：Safari 17 仍同时支持 MV2 与 MV3，但新特性只进 MV3，且 WebExtensions 已覆盖 iOS/iPadOS/xrOS（WWDC23: What's new in Safari extensions、WebKit Blog、WWDC21 iOS 版）。

结论：2026 年末"一次开发、多处上架"的现实组合是 CWS（付费但必选）＋ AMO/Edge（免费增量）；Safari 只在明确要覆盖 Apple 用户时才值得付出 App 审核与年度费用。

2.3 权限模型：为什么不能只写一份

（来源：Chrome declare-permissions、Chrome permissions API、Chrome userScripts、MDN host_permissions、MDN userScripts、MDN optional_permissions、Mozilla MV3 迁移指南、Mozilla MV3 Recap。）

• 最大分歧行：内容拦截类扩展在 Chrome/Safari 上只有 DNR 一条路。Safari 的 DNR 自 15 引入、16.4 起支持修改请求头与 redirect（需 declarativeNetRequestWithHostAccess 权限＋逐站点授权，见 WWDC23 会话原文），但阻塞式 webRequest 始终不支持（W3C webextensions #694 记录了生态对 Safari DNR 覆盖面的长期讨论）。Firefox 保留阻塞式 webRequest，正是 uBlock Origin 完整版在 Firefox 存活、Chrome 只能有 uBlock Origin Lite 的根因。
• 对个人效率扩展的实际影响：现代推荐模式是 activeTab＋optional_host_permissions＋按站点运行时请求＋动态注册 content script——首发零站点权限，安装转化率更高（Dev.to 实践、extpower）。注意：动态注册所用的 chrome.scripting API 需要额外的 scripting 权限——"manifest 只放 activeTab＋storage"的说法并不完整，最小清单与可照抄的 manifest 示例见 3.2 第 2 步。
• Firefox 的摩擦点：对"常驻监听"类需求（如要求 constant persistent listeners 的扩展）迁移 MV3 仍有困难（Mozilla Discourse）。

2.4 工程化：用什么骨架

（来源：2025 框架对比、Kanopy Labs、五框架实测、merginit、Extension.js 官方对比、2026 工具链对比。）

各评测对 WXT 的推荐并不完全同质，其结论构成如下（三份评测正文均于终稿修订时实际抓取核验）：五框架实测（extensionbooster，2026-02）用同一扩展实测五家后明确推 WXT 为生产项目默认——"Pick WXT unless you have a specific reason not to"，其实测中 WXT 构建 1.2s、包体 387KB 均为最小；Kanopy Labs（2026-04）是条件推荐——跨浏览器优先或 Vue/Svelte 团队选 WXT，React 重度团队则推 Plasmo；redreamality（2025-09 初版，2026-09-25 修订）在修订版中撤回了初版的"通用推荐"结论，理由是缺少可比基准与带日期的维护审计，仅保留三者分工描述。综合而言，可支撑的措辞是"多数近期评测倾向 WXT 作为新项目默认"，而非"一致推为默认"。对个人效率扩展（通常一个 popup＋一个 content script＋storage），本文采纳这一多数倾向：WXT 的 Vite 冷启动与多目标产物最贴合最小路径。

三、交叉洞察

3.1 两轴结合说明了什么

第一，横轴的每一行分歧行，都能在纵轴上找到成因事件。 Firefox 保留阻塞 webRequest 不是技术保守，而是它在 XUL 时代清零、WebExtensions 时代失去自主扩展叙事之后，仅存的差异化资产——2015 年"变成 Chrome 复制品"的批评 Mozilla 记了十年，MV3 就是它的回答。Chrome 的 DNR 是 2015 年广告注入研究（5% 日独立 IP 被注入广告）与常驻后台内存问题的双重终点。Safari 的 App Store 封闭分发与逐站点授权是苹果隐私叙事与商业模式的延伸，WWDC23 甚至宣布 Safari 17 连 App 扩展都改为按站点授权。不理解纵轴，就会把横轴差异误读为"哪家浏览器实现得不好"；实际上每家都在用 MV3 的名字交付自己战略意图的内容。

第二，平台权力已经定型，开发者是租户而非伙伴。 从 2010 年商店成立、2012 年强制 MV2、2021 年强制 2FA、2025–2026 年 MV2 物理清场，到 Publish API 版本化（v1 仅支持到 2026-10-15）与 Palant 对商店治理的公开批评，平台用二十年时间把"分发权、兼容权、存续权"全部收归己有。对开发者的含义是：工程纪律的本质是把平台的治理成本内部化——最小权限、无远程代码、可静态审计，这些不是道德建议，而是审核通过率与存续概率的直接变量。

第三，"跨浏览器"这个词已经分层瓦解。 API 层的分歧（callback vs promise、SW vs event page）已被 webextension-polyfill 与 WXT 等框架解决大半；真正剩下的是权限语义层（Chrome 运行时授予 vs Firefox 默认可选 vs Safari 逐站点——三者对"这个扩展能看到什么"的用户心智完全不同）与审核节奏层（CWS 数天 vs AMO 秒签到数周 vs App Review）。两轴交叉说明：2026 年做跨浏览器扩展，难的不是代码，而是权限策略与发布节奏的统筹。

第四，时机判断：2026 下半年至 2027 是 MV3 新常态的低风险窗口。 Chrome 商店清库刚走完（2026-08-31）、Edge 清退进行中（至 2027 年初）、Firefox 宣布双轨不设期限——平台规则第一次同时稳定；MV3 文档、框架（WXT/Plasmo）、样板工程全部成熟，坑都被前人踩过。此时入场，既没有 MV2/MV3 双轨的迁移税，也没有规则再变的政策风险。

3.2 对个人开发者的判断与建议：从零到上架的最小路径

综合两章的路径设计（纵轴四步版与横轴六步版在此合并为一条，消除重复），按"天"计：

• 第 0 步·形态降级检查（第 0 天）：需求里若没有 tabs/后台定时/跨标签/正式分发，先做 bookmarklet 或用户脚本——零审核零成本，按 2.1 的社区经验估计足以覆盖多数个人效率想法。这是纵轴 2004–2008 阶段（Greasemonkey 先于扩展平台存在）在今天的回声。
• 第 1 步·骨架（第 1 天）：WXT 初始化，单目标 Chrome MV3；UI 简单用原生 popup，重的上 React/Vue。不愿引框架就手写 manifest＋webextension-polyfill。
• 第 2 步·权限最小化（第 1 天）：manifest 声明 activeTab＋storage＋scripting 三个权限，host_permissions 留空，站点访问走 optional_host_permissions 按需请求。三个权限各自能做什么：
  • activeTab：用户调用扩展时（点工具栏图标、右键菜单项、快捷键、地址栏建议）临时授予当前标签页的访问权，安装时不触发任何权限警告，用户离开该页面即收回；期间可读取该标签页 URL/标题、并可注入脚本（Chrome: The activeTab permission，终稿修订时已抓取核验）。
  • storage：扩展自己的键值/字节存储（chrome.storage.local/sync），保存设置与状态，不涉及任何站点数据。
  • scripting：注入 API 的开关——executeScript() 一次性注入与 registerContentScripts() 动态注册都在 chrome.scripting 命名空间下，没有它动态注册无从谈起；因此"manifest 只放 activeTab＋storage"的老说法在 MV3 下并不自洽，最小清单应为三项（动态声明自 Chrome 96 引入，见 Chrome: Content scripts，终稿修订时已抓取核验）。

最小 manifest 示例（照此起步不会卡在第一步）：

  {
    "manifest_version": 3,
    "name": "my-tool",
    "version": "0.1.0",
    "permissions": ["activeTab", "storage", "scripting"],
    "optional_host_permissions": ["*://*/*"],
    "action": { "default_title": "运行" },
    "background": { "service_worker": "background.js" }
  }

两种注入路径与其权限要求：对"点一下才工作"的工具，用户点击图标即触发 activeTab，直接 scripting.executeScript() 对当前标签页生效（Chrome 官方 Page Redder 示例即 permissions: ["activeTab", "scripting"] 这一配置）；对"要在某站点常驻"的脚本，先经 permissions.request({ origins: [...] }) 弹窗申请该站点 host 权限（权限来源即 optional_host_permissions，Firefox/Chrome 均支持，用户可随时在扩展管理页授予或撤销），获批后再 scripting.registerContentScripts() 把 content script 注册到该站点（注册默认跨会话持久，persistAcrossSessions 可改为仅本次会话）。这一步决定安装转化率，且就 CWS 而言权限越窄通常审核越快、被拒概率越低（Firefox 的审核时长波动主要来自人工复审排队，与权限关系不大）——二十年权限模型演化最实用的工程纪律。

• 第 3 步·Chrome 首发（第 1–2 天＋审核期）：$5 一次性注册＋强制 2FA → zip 上传 → 填权限用途说明与隐私表单 → 等待审核（官方口径"多数扩展数天内完成"、不可加急，社区实测不一）。高频拒审原因是权限描述与实际申请不符，照实写、少申请。
• 第 4 步·Firefox/Edge 增量（第 3 天起）：WXT 换 build 目标产出 Firefox 版（service worker 自动映射 event page，不需要阻塞 webRequest 的效率类扩展几乎零改动），免费发 AMO——简单扩展自动签名分钟级，被标记转人工可能数周；同一包发 Edge Add-ons（免费、基本零改动）。
• 第 5 步·Safari 延后（可选）：只有需要 Apple 用户时，用 xcrun safari-web-extension-converter 打包宿主 App 走 App Review，为它单付 $99/年；注意 Safari 17 仍双轨支持 MV2/MV3，但新能力只进 MV3。
• 自用/小范围捷径：Chrome 走 unlisted（绕开公开检索但仍有审核）；Firefox 可 web-ext sign 签名后自托管（签名与分发、提交指南、web-ext 入门）；企业策略安装可保留 webRequestBlocking 等受限能力。

硬成本 ≈ $5（Chrome 一次性）＋ 0（Firefox/Edge）；软成本 ≈ 2–3 个工作日＋各店审核等待。 最可能卡住个人开发者的两个环节：Chrome 的权限说明填写，与 Firefox 的人工复审排队——前者靠诚实与克制解决，后者靠预期管理解决。

一句话判断：2026 年做个人效率扩展，正确的姿势是"用 bookmarklet 验证、用 WXT 起步、用最小权限过审、用 CWS 首发、用 AMO/Edge 增量、把 Safari 留给真正需要它的那天"。

3.3 风险与不确定性声明

• 审核时长与市场份额均为波动数据：本文份额为 Statcounter 页面表头当前显示的 2026 年 9 月月度值（综合与终稿修订两次抓取一致）。横轴原稿标注为"2026-10"的口径（Chrome ≈68.8% 等）与本文有约 2 个百分点的出入——两口径采集时点不同，且"2026-10 月度份额"在当前 Statcounter 页面上无法复现（可能对应图表中 10 月的当月/滚动视图），故本文不采用"以更新数据替换过时数据"的说法，而是：以官方页面当前显示的最新完整月为准，使用时应重新抓取 Statcounter 取最新月份，勿直接引用本文数字。
• Edge MV2 清退日程（2026-08 起禁用、预计 2027 年初移除）来自 AdGuard 社区记录，以微软官方页最新口径为准。
• Safari 的 $99/年费率为常见说法，本次未单独核验费率页。
• CWS Publish API v1 弃用（支持至 2026-10-15，本文成文时已过期）意味着自动化发布管线若仍走 v1 会失败，需确认已迁移 v2。
• 两章均注明：Chrome 浏览器 2008 年发布、IE BHO 背景、Firefox 57 日期等少量背景含模型既有常识，已在原章节标注，本综合报告沿用该说明。

四、参考来源

历史与发展（纵轴）

1. Chromium Blog, "Extensions beta launched, with over 300 extensions!" (2009-12-08) — https://blog.chromium.org/2009/12/extensions-beta-launched-with-over-300.html
2. Wikipedia, "Chrome Web Store" — https://en.wikipedia.org/wiki/Chrome_Web_Store
3. Wikipedia, "Greasemonkey" — https://en.wikipedia.org/wiki/Greasemonkey
4. Chrome for Developers, "Manifest version | Manifest V2"（Chrome 18 弃用 MV1、Chrome 23 强制 MV2）— https://developer.chrome.com/docs/extensions/mv2/manifestVersion
5. Google Security Blog, "New research: Ad injection economy" (2015-05-06) — https://security.googleblog.com/2015/05/new-research-ad-injection-economy.html
6. Kurt Thomas et al., "Ad Injection at Scale" (IEEE S&P 2015) — https://people.cs.uchicago.edu/~grantho/papers/oakland2015_ad_injection.pdf
7. Mozilla Add-ons Blog, "The Future of Developing Firefox Add-ons" (2015-08-21) — https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons
8. TechCrunch, "Chrome Extensions Are Coming To Firefox" (2015-08-21) — https://techcrunch.com/2015/08/21/chrome-extensions-are-coming-to-firefox
9. How-To Geek, "Firefox Is About To Become An Almost Complete Copy Of Chrome" (2015-09) — https://www.howtogeek.com/228131/firefox-is-about-to-become-an-almost-complete-copy-of-chrome
10. The Verge, Chromium Edge 发布 (2019-11-04) — https://www.theverge.com/2019/11/4/20942038/microsoft-edge-chromium-release-date-new-logo-features
11. TNW, Edge 开放扩展提交 (2019-12) — https://thenextweb.com/news/microsoft-wants-devs-to-submit-chromium-edge-add-ons-ahead-of-its-launch
12. TechRadar, "Microsoft Edge opens Add-ons store" (2020-02) — https://www.techradar.com/news/microsoft-edge-opens-add-ons-store
13. ghacks, "The Microsoft Edge extension store is finally getting some traction" (2020-03-02) — https://www.ghacks.net/2020/03/02/the-microsoft-edge-extension-store-is-finally-getting-some-traction
14. The Register, "Google's crackdown on ad blockers… Manifest V3 now available in beta" (2020-12-10) — https://www.theregister.com/security/2020/12/10/google-chromes-crackdown-on-ad-blockers-and-browser-extensions-manifest-v3-is-now-available-in-beta/
15. ZDNet, "First Chrome version with Manifest V3 to land in Canary this summer" (2019-06) — https://www.zdnet.com/article/first-chrome-version-with-manifest-v3-to-land-in-canary-this-summer
16. Chromium Blog, "Manifest V3 now available on M88 beta" (2020-12) — https://blog.chromium.org/2020/12/manifest-v3-now-available-on-m88-beta.html
17. EFF, "Google's Manifest V3 Still Hurts Privacy, Security, Innovation" (2021-12) — https://www.eff.org/deeplinks/2021/12/googles-manifest-v3-still-hurts-privacy-security-innovation
18. The Register, "Microsoft will adopt… Manifest V3 in Edge" (2020-10-15) — https://www.theregister.com/software/2020/10/15/microsoft-will-adopt-google-chromes-controversial-manifest-v3-in-edge/742676
19. Mozilla Discourse, "Request permissions at install time (Manifest V3)" — https://discourse.mozilla.org/t/request-permissions-at-install-time-manifest-v3/121543
20. Tampermonkey issue #644（MV3 迁移与 userScripts 限制）— https://github.com/Tampermonkey/tampermonkey/issues/644

MV2 退场与平台治理

1. Chrome for Developers, "Manifest V2 support timeline"（官方时间线，2024-06-03 / 2024-10-09 / 2025-03-31 / 2025-07-24 / 2026-08-31 全节点；纵轴成文时全文读取核验，页面标注最后更新 2026-09-09）— https://developer.chrome.com/docs/extensions/develop/migrate/mv2-deprecation-timeline
2. Bumbletap, "Chrome Deletes the Last Manifest V2 Extensions on August 31" — https://bumbletap.com/blog/chrome-manifest-v2-extensions-removed
3. AdGuard Blog, "Edge phasing out MV2 ad blockers" — https://adguard.com/en/blog/edge-phasing-out-mv2-ad-blockers.html
4. Mozilla Blog, "Mozilla's approach to Manifest V3" (2025-02-25) — https://blog.mozilla.org/en/firefox/firefox-manifest-v3-adblockers
5. Chrome for Developers, "Policy update: 2-Step Verification" (2021-06) — https://developer.chrome.com/blog/policy-update-2sv
6. Chrome for Developers, "Review process" — https://developer.chrome.com/docs/webstore/review-process
7. Wladimir Palant, "Chrome Web Store is a mess" (2025-01-13) — https://palant.info/2025/01/13/chrome-web-store-is-a-mess/
8. fregante/chrome-webstore-upload issue #114（Publish API v1 弃用至 2026-10-15）— https://github.com/fregante/chrome-webstore-upload/issues/114
9. Chromium Blog, "New developer dashboard"（$5 注册费，2020-03）— https://blog.chromium.org/2020/03/new-developer-dashboard-and.html
10. Chrome for Developers, "Register as a Chrome Web Store developer" — https://developer.chrome.com/docs/webstore/register

MV3 规范与权限模型

1. Chrome for Developers, "What is Manifest V3?" — https://developer.chrome.com/docs/extensions/develop/migrate/what-is-mv3
2. Chrome for Developers, "Blocking web requests" — https://developer.chrome.com/docs/extensions/develop/migrate/blocking-web-requests
3. Chrome for Developers, "Declare permissions" — https://developer.chrome.com/docs/extensions/develop/concepts/declare-permissions
4. Chrome for Developers, permissions API — https://developer.chrome.com/docs/extensions/reference/api/permissions
5. Chrome for Developers, userScripts API（Chrome 120+）— https://developer.chrome.com/docs/extensions/reference/api/userScripts
6. Extension Workshop, "Manifest V3 migration guide" — https://extensionworkshop.com/documentation/develop/manifest-v3-migration-guide/
7. Mozilla Add-ons Blog, "Manifest V3 in Firefox: Recap & Next Steps" (2022-05-18) — https://blog.mozilla.org/addons/2022/05/18/manifest-v3-in-firefox-recap-next-steps
8. MDN, host_permissions — https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/host_permissions
9. MDN, optional_permissions / optional_host_permissions（运行时请求站点权限；用户可在扩展管理页随时授予/撤销；终稿修订时已抓取 optional_host_permissions 页核验）— https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/optional_host_permissions
10. MDN, userScripts API — https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/userScripts
11. Edge MV3 迁移（Microsoft Learn）— https://learn.microsoft.com/en-us/microsoft-edge/extensions/developer-guide/manifest-v3
12. W3C webextensions issue #694（Safari DNR 能力讨论）— https://github.com/w3c/webextensions/issues/694
13. Dev.to, "Ask for one site at a time: optional host permissions and dynamic content scripts in MV3" — https://dev.to/emirmrkaljevic/ask-for-one-site-at-a-time-optional-host-permissions-and-dynamic-content-scripts-in-mv3-3b7c
14. extpower.dev, "Permissions vs host_permissions (Manifest V3)" — https://extpower.dev/blog/permissions-vs-host-permissions-manifest-v3
15. Mozilla Discourse, "Impossible to upgrade to MV3 for extensions that require constant persistent listeners" — https://discourse.mozilla.org/t/impossible-to-upgrade-to-manifest-v3-for-extensions-that-require-constant-persistent-listeners/125942
16. Chrome for Developers, "The activeTab permission"（activeTab 语义：调用时临时授予当前标签页、安装时无警告、配合 scripting 权限注入；终稿修订时已抓取核验）— https://developer.chrome.com/docs/extensions/develop/concepts/activeTab
17. Chrome for Developers, "Content scripts"（动态声明 Chrome 96+、registerContentScripts/executeScript、程序化注入需 host 权限或 activeTab；终稿修订时已抓取核验）— https://developer.chrome.com/docs/extensions/develop/concepts/content-scripts

跨浏览器与上架（Edge / Firefox / Safari）

1. Windows Blog, "Empowering Microsoft Edge Add-ons developers with faster reviews" (2025-02-26) — https://blogs.windows.com/msedgedev/2025/02/26/empowering-microsoft-edge-add-ons-developers-with-faster-reviews
2. microsoft/MicrosoftEdge-Extensions discussion #784（认证时长）— https://github.com/microsoft/MicrosoftEdge-Extensions/discussions/784
3. Mozilla Discourse, "Is it normal for Firefox add-on review to take this long?" (2025-03) — https://discourse.mozilla.org/t/is-it-normal-for-firefox-add-on-review-to-take-this-long/141854
4. Apple Developer, "Packaging a web extension for Safari" — https://developer.apple.com/documentation/safariservices/packaging-a-web-extension-for-safari （本次综合时已抓取核验）
5. Apple Developer, "Distributing your Safari web extension" — https://developer.apple.com/documentation/safariservices/distributing-your-safari-web-extension
6. Apple, Safari Extensions 官方页 — https://developer.apple.com/safari/extensions
7. Apple, App Review Guidelines — https://developer.apple.com/app-store/review/guidelines
8. MacRumors, "Apple Reminds Developers That Safari 14 Supports Web Extensions" (2020-08-28) — https://www.macrumors.com/2020/08/28/safari-web-extensions/
9. Apple WWDC21, "Meet Safari Web Extensions on iOS" — https://developer.apple.com/videos/play/wwdc2021/10004/
10. Apple WWDC23, "What's new in Safari extensions"（本次综合时已抓取全文核验；Safari 17 双轨支持 MV2/MV3、DNR 16.4 起支持改头与 redirect、App 扩展逐站点授权）— https://developer.apple.com/videos/play/wwdc2023/10119
11. WebKit Blog, "WebKit Features in Safari 17.0" (2023-09-18) — https://webkit.org/blog/14445/webkit-features-in-safari-17-0

工具链与工程化

1. Mozilla Hacks, "Developing cross-browser extensions with web-ext 3.2.0" (2019-10) — https://hacks.mozilla.org/2019/10/developing-cross-browser-extensions-with-web-ext-3-2-0
2. mozilla/web-ext (GitHub) — https://github.com/mozilla/web-ext
3. Extension Workshop, "Getting started with web-ext" — https://extensionworkshop.com/documentation/develop/getting-started-with-web-ext
4. Extension Workshop, "Submitting an add-on" — https://extensionworkshop.com/documentation/publish/submitting-an-add-on
5. Extension Workshop, "Signing and distribution overview" — https://extensionworkshop.com/documentation/publish/signing-and-distribution-overview
6. redreamality, "The 2025 State of Browser Extension Frameworks: Plasmo vs WXT vs CRXJS"（2025-09-03 初版；2026-09-25 修订版撤回初版"通用推荐"结论，理由为缺少可比基准与带日期的维护审计；终稿修订时已抓取核验）— https://redreamality.com/blog/the-2025-state-of-browser-extension-frameworks-a-comparative-analysis-of-plasmo-wxt-and-crxjs
7. Kanopy Labs, "WXT vs Plasmo vs Extension.js"（2026-04；条件推荐：跨浏览器或 Vue/Svelte 团队选 WXT，React 重度团队推 Plasmo；终稿修订时已抓取核验）— https://kanopylabs.com/blog/wxt-vs-plasmo-vs-extension-js
8. extensionbooster, "Best Chrome Extension Frameworks Compared"（2026-02；同一扩展五框架实测，推 WXT 为生产项目默认；终稿修订时已抓取核验）— https://extensionbooster.net/blog/best-chrome-extension-frameworks-compared
9. merginit, "Plasmo vs WXT vs CRXJS vs Extension.js" — https://merginit.com/blog/23082026-plasmo-vs-wxt-vs-crxjs-extension-js
10. Extension.js, 官方对比页 — https://extension.js.org/docs/compare
11. plugthis.ai, "Chrome Extension Development Tools Comparison 2026" — https://plugthis.ai/blog/chrome-extension-development-tools-comparison-2026

形态对比与数据

1. Stack Overflow, "PWA vs Electron vs Browser Extension" — https://stackoverflow.com/questions/50705226/progressive-web-apppwa-vs-electron-vs-browser-extension
2. Reddit r/userscripts, "Userscripts vs extensions" — https://www.reddit.com/r/userscripts/comments/fruy3k/userscripts_vs_extensions
3. Tampermonkey 官网 — https://www.tampermonkey.net
4. Hacker News #34830825（bookmarklet 跨端观点）— https://news.ycombinator.com/item?id=34830825
5. Kanopy Labs, "Chrome Extension vs Web App: Which to Build" — https://kanopylabs.com/blog/chrome-extension-vs-web-app-which-to-build
6. Statcounter Global Stats, Browser Market Share（页面表头当前显示 September 2026 月度表：Chrome 66.36% / Safari 18.27% / Edge 6.04% / Firefox 2.8%；综合与终稿修订（2026-11-06）两次抓取一致）— https://gs.statcounter.com/browser-market-share

*（说明：Firefox 57 于 2017 年使 WebExtensions 成为唯一扩展类型、Chrome 浏览器 2008 年发布、IE BHO 背景等少量表述含模型既有常识，已在原章节标注；其余事实均可在上列来源直接核对。本文为按独立审读意见修订后的终稿，修订记录见下附录；初稿保留于 drafts/ 目录未改动。）*

附录：审读意见修订记录（终稿）

终稿修订时新抓取核验的来源：Statcounter（市场份额表头）、redreamality / Kanopy Labs / extensionbooster（三份框架评测结论）、Chrome 官方 activeTab 与 Content scripts 文档、MDN optional_host_permissions 页。