WXT多浏览器上架全攻略：Chrome/Firefox/Edge/Safari发布与审核

本节目标：了解四大商店的上架流程与差异，掌握 wxt submit 自动化提交的原理与选项，理解审核、灰度与常见拒因，以及付费功能的接入思路。本章是知识点讲解，具体操作以各商店官方文档为准。

上架流程全景

每家商店的流程都差不多：开发者账号 → 准备包 → 填写商店信息 → 上传提交 → 审核 → 发布。WXT 只自动化其中两部分：打包（如 §38 所述）和提交（wxt submit）。首次上架没法自动化——创建商品页、填隐私表单、传截图，都得在商店后台人工完成。

各商店基本情况：

商店	开发者费用	包要求	WXT 自动化
Chrome Web Store	一次性 $5	zip	wxt submit 支持
Firefox Addon Store	免费	zip + 源码 zip	wxt submit 支持
Edge Addons	免费	可复用 Chrome 的 zip	wxt submit 支持
Safari	需 Apple 开发者账号	必须包一层原生 App	不支持

Safari 特殊：WXT 不做 Safari 自动化。Safari 扩展必须用 Xcode 包成原生 macOS / iOS App，官方工具 safari-web-extension-packager 接收的是 .output/safari-mv2 构建目录。另外 wxt submit 还支持 Opera（—opera-* 选项）。

Chrome 上架要点（中国开发者视角）

以下内容参考社区资料整理，具体政策以 Chrome Web Store 官方文档为准：

注册开发者账号：Google 账号登录开发者控制台，支付一次性 $5 注册费，填写开发者名称、邮箱、地址；
准备材料：128x128 图标（必须）、截图（1280x800 或 640x400，建议 3–5 张）、简短描述（132 字符内）、详细描述、类别、支持链接；
隐私：收集任何用户数据都要提供隐私政策 URL；每个权限写清楚用途；有付费功能的扩展，在「审核者备注」里提供测试账号，能明显加快审核；
审核时间线：自动检查几分钟到几小时，人工审核通常 1–7 天，首次提交更慢，节假日和复杂权限会更久；
常见拒因：权限滥用（申请了用不到的权限）、元数据不符（描述、截图与功能不符）、政策违规（未授权收集数据、误导性描述）、技术问题（无法运行、安全漏洞）；
发布范围：公开、未列出（unlisted）、私有，也可以按百分比灰度。

被拒后怎么办：读拒绝邮件 → 修改代码和商店信息 → 本地充分测试 → 版本号 +1 重新打包 → 在提交说明里写清改了什么。

wxt submit：一次提交多家商店

wxt submit 是 publish-browser-extension 包的别名，负责「上传 zip 并提交审核」，不负责创建商品页。它有三个子命令：init（初始化配置）、status（查状态）、set-deploy-percentage（调整灰度比例）。

第一步，交互式初始化：

wxt submit init

按提示回答各商店的问题，生成 .env.submit 文件，所有 secrets 和选项都存在里面。CI 里要把这些环境变量注入到提交步骤。

第二步，打包（如 §38 所述）：

wxt zip
wxt zip -b firefox

第三步，先用 —dry-run 验证 secrets 能不能通过认证：

wxt submit --dry-run \
  --chrome-zip .output/my-ext-1.0.0-chrome.zip \
  --firefox-zip .output/my-ext-1.0.0-firefox.zip \
  --firefox-sources-zip .output/my-ext-1.0.0-sources.zip \
  --edge-zip .output/my-ext-1.0.0-chrome.zip

通过后去掉 —dry-run 正式提交。Edge 直接复用 Chrome 的 zip。

各商店的认证方式不同：

Chrome：新版走 CWS API v2，需要 service account 的 client email、private key 和 publisher ID；旧版 v1.1（client id / secret / refresh token）已标废弃；
Firefox：JWT（issuer + secret）+ 扩展 ID，支持 listed / unlisted 渠道；
Edge：client id + product id + API key。

提交选项里几个实用的：—chrome-deploy-percentage 0–100 控制灰度；—chrome-publish-type STAGED_PUBLISH 先提交不发布；—chrome-cancel-pending 取消排队中的旧审核；—chrome-skip-review 部分更新（如规则更新）可跳过审核直接发布。

审核期间反复提交会互相排队阻塞，旧版本卡住新版本。排队中有旧审核时，先 cancel 再提交。

接进 CI

GitHub Actions 的标准姿势：手动触发 → 安装依赖 → zip → submit。secrets 从仓库设置注入，永远不要写进仓库代码：

name: Release
on:
  workflow_dispatch:
jobs:
  submit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: pnpm/action-setup@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: 'pnpm'
      - name: Install dependencies
        run: pnpm install
      - name: Zip extensions
        run: |
          pnpm zip
          pnpm zip:firefox
      - name: Submit to stores
        run: |
          pnpm wxt submit \
            --chrome-zip .output/*-chrome.zip \
            --firefox-zip .output/*-firefox.zip \
            --firefox-sources-zip .output/*-sources.zip
        env:
          CHROME_EXTENSION_ID: ${{ secrets.CHROME_EXTENSION_ID }}
          CHROME_CLIENT_ID: ${{ secrets.CHROME_CLIENT_ID }}
          CHROME_CLIENT_SECRET: ${{ secrets.CHROME_CLIENT_SECRET }}
          CHROME_REFRESH_TOKEN: ${{ secrets.CHROME_REFRESH_TOKEN }}
          FIREFOX_EXTENSION_ID: ${{ secrets.FIREFOX_EXTENSION_ID }}
          FIREFOX_JWT_ISSUER: ${{ secrets.FIREFOX_JWT_ISSUER }}
          FIREFOX_JWT_SECRET: ${{ secrets.FIREFOX_JWT_SECRET }}

构建成功、CI 变绿，都不代表可以发布。首次发布、隐私表单、截图、审核沟通，通常仍要人工在商店后台完成。上架不是自动授权。

付费功能：官方支付已停，走第三方

Chrome Web Store 官方支付自 2020 年起不再支持新的付费扩展。新扩展想收费，只能接第三方支付（Stripe、Paddle、Lemon Squeezy 等）。

典型架构是：扩展 ↔ 你的后端 ↔ 支付平台。流程：扩展发起购买 → 后端创建 Checkout 会话 → 用户在新标签页付款 → 支付平台 Webhook 通知后端 → 后端更新许可证状态 → 扩展定期查询、按状态解锁功能。

安全要点：前端不存密钥和许可证状态，验证都在后端；校验 Webhook 签名；限制许可证设备数；通信走 HTTPS。审核时记得在「审核者备注」里提供测试账号。

小结

上架是流程活，不是技术活：打包交给 WXT，提交交给 wxt submit。
商品页、隐私政策、审核沟通这些「文案与流程」环节，耐心按官方要求填就好。

发布上架：Chrome / Firefox / Edge / Safari

上架流程全景

Chrome 上架要点（中国开发者视角）

wxt submit：一次提交多家商店

接进 CI

付费功能：官方支付已停，走第三方

小结