Edge 与 Firefox 发布

Chrome 之外，Edge 和 Firefox 是另外两个主流渠道。好在它们都基于 Chromium 或兼容 WebExtensions，你前面写的扩展改动不大就能复用。

这一节把两个商店的提交流程分开讲，照着做就行。

49-1 Edge Add-ons 是怎么回事

Edge 基于 Chromium，对 MV3 扩展的兼容度很高。同一份 chrome.* 代码在 Edge 里通常一行不改就能跑。

Edge 的开发者后台挂在微软的合作伙伴中心（Partner Center）。你需要一个微软账号，并完成开发者身份校验。和 Chrome 不同，Edge 目前没有一次性注册费，这点对新手很友好。

49-2 Edge 的提交步骤

标准流程走一遍：

1. 登录 Edge Add-ons 开发者后台，新建一个扩展提交。
2. 上传方式二选一：传 zip 包（结构要求和 Chrome 一致，manifest.json 在根），或者填 Chrome Web Store 链接自动导入。
3. 填写商品详情：名称、描述、图标、截图、分类、语言。文案要求和 Chrome 接近，但展示尺寸略有差别，截图最好按 Edge 的推荐尺寸单独准备一套。
4. 设置可见性：公开上架、隐藏（仅链接可装）、或私有（组织内可见）。
5. 提交审核。Edge 没有对外承诺的固定工期，结果通过邮件通知。

导入方式虽然快，我还是建议你人工核对一遍资料。自动拉来的截图和描述未必贴合 Edge 的展示规则，漏改也可能被打回。

49-3 Edge 的几个注意点

有三件事容易被忽略，提前记下：

扩展 ID 不通用。Edge 和 Chrome 的 ID 体系彼此独立，同一个扩展在两边 ID 不一样。别在代码里写死某个 Chrome 扩展 ID 当通用标识。

商店链接不一样。Edge 有自己的商品页地址，你在官网或文档里引导用户安装时，要按浏览器给对应链接。

版本要各自维护。两个商店的审核节奏不同步，很可能出现 Chrome 已经是 1.3、Edge 还停在 1.2 的情况。发版时逐个渠道确认，别以为传一次就三端都更新了。

49-4 Firefox Add-ons 概览

Firefox 走的是自己的 AMO（addons.mozilla.org）体系。它同样支持 Manifest V3，但 API 命名空间用 browser.* 而不是 chrome.*，且大量接口直接返回 Promise。

好消息是后面「跨浏览器兼容」模块会讲 webextension-polyfill，它能把两套命名空间统一起来。代码里用了 polyfill，上 Firefox 基本零改动。这一节先只聚焦「怎么发」，兼容细节留到模块十二。

Firefox 的后台叫开发者中心，用 Firefox 账号登录即可，同样没有注册费。

49-5 用 web-ext 打包 xpi

Firefox 上架的是 .xpi 文件，本质就是 zip 换了后缀。官方推荐用 web-ext 命令行工具处理，它能打包、校验，还能起一个干净的浏览器实例调试。

先全局安装：

npm install -g web-ext

进入扩展目录执行打包：

# 在当前目录打包，产物在 web-ext-artifacts/ 下
web-ext build

打包前先跑一遍自检，它会指出清单和代码里的潜在问题：

web-ext lint

lint 非常实用。很多上传后才被拒的问题，本地这一步就能提前抓到。我建议养成「打包前先 lint」的习惯。

想边改边看效果，还可以直接起调试实例：

# 启动一个临时 Firefox 并加载当前扩展，改文件自动重载
web-ext run

49-6 Firefox 专属字段 browser_specific_settings

Firefox 有个 Chrome 没有的清单字段，值得单独记一下：browser_specific_settings.gecko。它用来声明 Firefox 专属信息，最常用的是扩展 ID。

{
  "manifest_version": 3,
  "name": "我的扩展",
  "version": "1.0.0",
  "browser_specific_settings": {
    "gecko": {
      "id": "my-extension@example.com",
      "strict_min_version": "115.0"
    }
  }
}

两个字段的含义：

• id：Firefox 里扩展的唯一标识，用邮箱风格的字符串即可。不写的话分两种情况：用 web-ext run 等临时加载方式会每次自动生成随机 ID；提交 AMO 时 Mozilla 会代为分配一个稳定 ID 并写回清单。为了存储数据和更新的连续性，正式发布仍建议显式写死。
• strict_min_version：声明支持的最低 Firefox 版本，低于它的用户装不上。

49-7 Firefox 的审核差异：公开与不公开

Firefox 上架分两条路线，审核力度差别很明显。

公开列表会出现在 AMO 的搜索和分类里。这类扩展要走完整人工审核，审核员会实际安装、审查代码，尤其关注权限用途和隐私处理。耗时从几天到更久不等。

不公开不进 AMO 列表，用户靠你给的链接安装。这类走自动验证，通常几秒到几分钟就能通过，适合内测或自己分发。

有个现实要注意：Firefox 的人工复查也可能发生在上架之后。发现问题会要求整改，严重的直接停用。所以别以为一次通过就万事大吉。

49-8 Firefox 自托管更新

不走 AMO 公开列表、打算自己托管时，需要在清单里声明 update_url，告诉 Firefox 去哪查更新：

{
  "browser_specific_settings": {
    "gecko": {
      "id": "my-extension@example.com",
      "update_url": "https://myhost.com/my-ext/updates.json"
    }
  }
}

服务器上那份更新清单用 JSON 格式，Firefox 约定的结构大致是这样：

{
  "addons": {
    "my-extension@example.com": {
      "updates": [
        {
          "version": "1.1.0",
          "update_link": "https://myhost.com/my-ext/my-ext-1.1.0.xpi"
        }
      ]
    }
  }
}

浏览器定期访问 update_url，发现远端版本比本地高就拉新包安装。注意自托管的 xpi 仍需经过 Mozilla 签名，否则正式版 Firefox 会拒绝安装。

这属于进阶分发方式，走 AMO 的用户用不到。知道有这条路径就够，真要做再细查官方文档。

49-9 三端发布对照

把三个商店放一起看，差异一目了然：

渠道	注册费	包格式	审核方式	命名空间
Chrome Web Store	一次性费用	zip	自动扫描 + 人工	chrome.*
Edge Add-ons	无	zip / 从 CWS 导入	人工，无固定工期	chrome.*
Firefox AMO	无	xpi（本质是 zip）	公开走人工 / 不公开自动	browser.*

核心结论：以 chrome.* 为主线写的 MV3 扩展，配合 webextension-polyfill 就能基本覆盖三端。发布环节各填一遍资料，没有哪家需要你重写业务逻辑。

49-10 小结

Edge 走合作伙伴中心，可以从 Chrome Web Store 直接导入资料，无注册费，但扩展 ID 和商店链接都和 Chrome 独立，版本要各渠道分别维护。

Firefox 走 AMO，用 web-ext build 打 xpi、用 web-ext lint 提前查错，并通过 browser_specific_settings.gecko 写死扩展 ID 和最低版本。公开列表走人工审核，不公开走自动验证，还可以用 update_url 自托管，但 xpi 仍需签名。

三个商店都对 MV3 友好，一份核心代码多端发布不是难事。下一节讲版本更新和上线后的日常维护。