从 zip 包到商店页：浏览器扩展上架的 7 道坎

vibe coding 把"做一个浏览器扩展"的门槛打穿了：一个周末，一句提示词，popup 弹得出、按钮按得动。但从"本地能跑"到"商店页上赫然在列"，中间隔着另一套游戏规则——审核员不关心你的提示词写得多漂亮，只关心权限是不是越界、代码里有没有远程加载、隐私声明能不能自圆其说。这篇文章把 zip 包变成商店页之间的 7 道坎一次讲透：选哪家店、MV3 的坑、权限、隐私政策、物料、被拒急救、发版后动作。每节都站在一人开发者的视角：要做什么判断、花多少时间、哪里最容易翻车。

一、先选战场：三家商店决策表

别一上来就三家全上。先想清楚你的扩展为谁而做：Chrome 用户盘子最大，但审核最磨人；Edge 零费用、同一个包几乎零改动，是验证水温的低成本起点；Firefox 有自己的一套代码审查哲学，代码写得干净的人反而更顺。三家之间不是难度排序，是取舍排序。

维度	Chrome Web Store	Edge Add-ons	Firefox AMO
注册费用	$5，一次性	免费	免费
首发审核时长	通常 1–3 个工作日；敏感权限或触发人工审核可达 1–3 周	1–7 个工作日	自动校验即时通过，人工审核数小时到数周不等
更新审核	多在 24 小时内，有的几小时就过	同首发，走同一队列	有上架记录后比首发快，通常几天内
审核严在哪	权限与政策合规：host 权限宽度、远程代码禁令、单一用途原则	与 Chrome 同源的 Chromium 政策，体感更顺滑	代码本身：混淆或压缩过的代码必须另交源码；data_collection_permissions 声明必填（2025 年 11 月起对新提交强制）
用户规模	最大，Chrome 约占浏览器市场三分之二	Edge 用户，3 亿+	小于 Chrome，但用户忠诚度和付费意愿口碑更好
技术门槛	只收 MV3；2026 年 8 月 31 日最后一批 MV2 已从商店下架	与 Chrome 同一套 MV3 包，基本零改动	支持 MV3，但后台是 event page（background.scripts）而非 service worker，需单独适配

取舍建议很直接：只做 Chromium 系，先上 Edge 练手再攻 Chrome——Edge 免费、审核快，同一套包，等于一次免费的"预审核"；要覆盖 Firefox，就把 AMO 的源码可读性要求前置到开发阶段，用了构建工具就保留未压缩源码，别等提交了再返工。三个开发者后台分别是 Chrome Web Store 开发者控制台、Microsoft Partner Center（Edge）、AMO 开发者中心，账号体系互相独立，发布者名称建议三家统一。

还有一个容易被忽略的决策点：第一版打算公开发布，还是先 unlisted（凭链接安装）小范围验证？Chrome 和 Edge 都支持 unlisted/listed 之外的可见度选项，审核流程一样走，但能避开公开页的差评冷启动。对 vibe coder 来说，先 unlisted 跑一两周、确认崩溃率和核心流程没问题再转公开，是成本最低的试错路径。

二、MV3 迁移清单：AI 最爱踩的 5 个坑

先把时间线钉死：2025 年 7 月 Chrome 138 起，MV2 扩展在所有渠道被彻底禁用，用户再也打不开了；2026 年 8 月 31 日，Chrome Web Store 下架了最后一批 MV2 条目。今天讨论的不是"要不要迁 MV3"，而是"迁的时候别掉进这 5 个坑"。AI 编程工具的训练语料里混着大量 MV2 时代的老教程，它生成代码时不会主动告诉你那是过期写法——每个坑后面都跟一句"让 AI 自查的话术"，直接复制去问你的 AI。

坑 1：service worker 会"死"，别再写常驻后台

MV3 的后台是 service worker，浏览器会在空闲时随时杀掉它。全局变量里缓存的状态、setInterval 写的定时任务，都会在你不注意的时候凭空消失。症状非常典型：本地测试一切正常，上架后用户反馈"有时候不工作"——因为本地调试时 DevTools 开着，service worker 一直活着，你根本复现不了被杀掉的场景。修法只有一条：状态一律走 chrome.storage，定时任务一律走 chrome.alarms。给 AI 的自查话术："检查 background 脚本，把所有 setInterval/setTimeout 换成 chrome.alarms，凡是存在全局变量里的状态，改存 chrome.storage.local，并处理 service worker 重启后从 storage 恢复状态的逻辑。"

// ❌ MV2 思维：指望后台一直活着
let cache = {};
setInterval(() => syncData(cache), 60000);

// ✅ MV3 写法：状态落盘，定时走 alarms
chrome.alarms.create('sync', { periodInMinutes: 1 });
chrome.alarms.onAlarm.addListener(async (alarm) => {
  if (alarm.name === 'sync') {
    const { cache } = await chrome.storage.local.get('cache');
    syncData(cache || {});
  }
});

坑 2：host_permissions 和 permissions 分家了

MV3 把网址匹配从 permissions 里拆了出来，单独叫 host_permissions。AI 按老记忆可能把 <all_urls> 写进 permissions，或者把 host 模式写错位置，打包时不报错，审核时直接被挑出来。更要命的是第二层：host_permissions 越宽，越容易触发人工审核。<all_urls> 基本等于举着牌子告诉审核员"来仔细查我"。原则是：能写具体域名就不写通配，能用 activeTab 解决就不申请 tabs + host 权限。给 AI 的自查话术："列出扩展实际访问的域名清单，把 host_permissions 收敛到最小集合；凡是只在用户点击时操作当前页的场景，改用 activeTab 并删掉对应的 host 声明。"

坑 3：远程代码禁令——CDN 引入直接判死刑

Chrome Web Store 明令禁止执行远程托管的代码：<script> 标签拉 CDN 的库、动态 import() 远程模块、从服务器拉配置再 eval，全部不行。AI 生成代码特别爱干这事——为了"保持轻量"用 CDN 引一个工具库，为了"可配置"从接口拉一段规则脚本。本地跑得好好的，审核直接拒，而且这条没有申诉空间，属于政策红线。修法：所有依赖打包进 zip；构建产物保持可读，过度混淆的代码审核员同样会找你麻烦。给 AI 的自查话术："扫描所有 HTML 和 JS，找出一切外部 <script src>、动态 import() 和 eval/new Function，全部改为本地打包引入；确认 zip 里不包含任何运行时从网络加载执行的代码。"

坑 4：阻塞式 webRequest 没了，改 declarativeNetRequest

MV2 时代靠 chrome.webRequest 的 blocking 模式拦截、改写网络请求，MV3 砍掉了阻塞能力，换成声明式规则 declarativeNetRequest：你提前把规则交给浏览器，浏览器自己执行，扩展代码看不到请求内容。AI 按 2023 年以前的教程生成的拦截代码，在 MV3 下会静默失效——不报错，就是不工作，这是最阴险的一种。凡是涉及广告拦截、请求改写、Header 篡改的扩展，这不是"迁移"，是"重写"，排期时按重做估算，别按迁移估算。给 AI 的自查话术："把 webRequest blocking 逻辑逐条翻译成 declarativeNetRequest 规则，列出哪些动态判断逻辑无法用静态规则表达，改用其他方案或砍掉该功能。"

坑 5：CSP 干掉了内联脚本，onclick 写了也白写

MV3 的默认内容安全策略禁止内联脚本和 eval。AI 生成的 popup.html 里最爱写 <button onclick="doSomething()">——在扩展里这行代码等于不存在，点击没反应，控制台还不一定报错，vibe coder 能对着它调一下午。修法：全部改成 addEventListener。给 AI 的自查话术："扫描所有 HTML 文件，找出全部内联事件处理器（onclick、onchange 等）和内联 <script>，迁移到外部 JS 文件用 addEventListener 绑定。"

附带一个跨浏览器差异，提前知道能省一次返工：Firefox 的 MV3 后台不是 service worker，而是沿用 event page（background.scripts）。同一套代码发 Firefox 要做分支处理，"一次编写处处运行"在最后一公里并不成立。务实的办法是维护两份 manifest（manifest.chrome.json / manifest.firefox.json），构建时按目标切换，JS 主体尽量共享。

下面是一个干净的 MV3 manifest 起点，权限按"够用即止"配好，下一节会逐条解释为什么这样写：

{
  "manifest_version": 3,
  "name": "Your Extension",
  "version": "1.0.0",
  "description": "一句话说清它干什么",
  "action": { "default_popup": "popup.html" },
  "background": { "service_worker": "background.js" },
  "permissions": ["storage", "alarms"],
  "host_permissions": ["https://api.example.com/*"],
  "icons": {
    "16": "icons/icon-16.png",
    "48": "icons/icon-48.png",
    "128": "icons/icon-128.png"
  }
}

三、权限最小化："够用即止"与 3 类高频被拒理由

审核员看扩展，第一眼永远是 manifest 的权限声明。权限是扩展的"资产负债表"：每多一项，都是你欠审核员的一个解释。原则只有四个字：够用即止。不是"以防万一先申请上"，而是"这个功能没有它就做不成，我才申请它"。下面 3 类被拒理由，覆盖了权限相关的绝大多数拒信，对着它们逐条自查，通过率至少翻一倍。

被拒理由 1：权限与功能对不上

最高频，没有之一。申请了 <all_urls>，实际只读一个站的数据；申请了 tabs，实际只在用户点击时操作当前标签页（activeTab 就够了）；申请了 cookies，代码里一次都没读过 cookie。审核员的逻辑很简单：你要的比你用的多，要么是你不懂自己在干什么，要么是你想干点别的——两种都不给过。自查方法：让 AI 逐个权限输出"哪行代码用了它"，输出不出来的，删。删完再跑一遍完整功能测试，vibe coder 最大的敌人就是"删了不敢测"，而这一步恰恰不能省。

被拒理由 2：敏感权限没有书面 justification

Chrome Web Store 的提交流程里有个 privacy（隐私权）标签页，要求你为每个权限写一句话说明用途。空着不写，或者写"为了给您更好的体验"这种正确的废话，等于主动申请被拒。写法模板是固定的三段式：这个权限用来做什么 → 没有它哪个功能会坏 → 数据去哪了（只存本地 / 发到哪个域名）。例如 storage："用于在本地保存用户的主题与快捷键设置；不申请则设置无法持久化；数据仅保存在浏览器本地，不上传。" 提前写好这段话还有一个好处：它会倒逼你重新审视每个权限到底值不值得留。

被拒理由 3：僵尸权限——功能删了，声明没删

迭代几次之后，manifest 里躺着两三个早就没人用的权限，这是 AI 重构代码的典型后遗症：功能砍了，声明还在，因为"删权限"不在 AI 的默认检查清单里。审核员可不管你的迭代史，他只看到现在的代码配不上现在的声明。自查话术："对比 manifest 里每一项 permissions/host_permissions 和当前代码的实际调用，删除零引用的声明，并解释保留的每一项为什么删不掉。" 把这句话加进你每次发版前的 checklist，比什么都管用。

最后给一个判断标准，帮你决定某个权限该不该留：如果向一个不懂技术的朋友解释"为什么这个扩展需要这个权限"时你自己都心虚，那就别申请。审核员的心智和你朋友是一样的。权限收敛还有一个隐性收益：权限越少，触发人工审核的概率越低，首发 1–3 天过的多半都是权限干净的扩展。

四、隐私政策与数据披露：30 分钟写出过审版本

一人开发者最容易在这件事上内耗：觉得隐私政策是法务文件，要么拖着不写，要么复制一份大公司的模板改改了事——后者更危险，模板里写的收集行为和你的扩展实际行为对不上，审核员一眼就能看出来。真相是：对绝大多数 vibe 做的扩展来说，隐私政策只有一页纸，而且"我们什么都不收集"本身就是最有力的声明。关键不在于写得多漂亮，而在于"声明"和"实际行为"严格一致。

30 分钟的写法：先花 10 分钟诚实回答 4 个问题——扩展收集了什么数据？数据存在哪（本地 / 自己的服务器 / 第三方）？有没有第三方 SDK 或接口调用？用户怎么联系你删除数据？然后花 20 分钟把答案填进下面的模板。模板里的方括号是必改项，别偷懒留着原文：

[扩展名称] 隐私政策（最后更新：[YYYY-MM-DD]）

1. 我们收集什么：[扩展名称] [不收集任何个人数据 / 仅收集以下数据以实现核心功能：[例如：用户主动输入的 API Key]]。我们不收集浏览历史、不追踪用户行为、不投放广告。

2. 数据存在哪：所有设置与数据仅保存在您浏览器的本地存储（chrome.storage）中，不会上传到我们的服务器。[如有云同步/自有接口，改为：以下数据会传输到 [域名/用途]，传输过程使用 HTTPS 加密。]

3. 第三方服务：[本扩展不调用任何第三方服务 / 本扩展调用 [服务名]（[域名]）以实现 [功能]，相关数据的处理适用该服务的隐私政策。] 本扩展不含任何广告 SDK 与行为分析 SDK。

4. 权限说明：本扩展申请的浏览器权限（[例如：storage、activeTab]）仅用于实现 [一句话功能描述]，权限清单与用途见商店页面的权限说明。

5. 联系我们：如果您对本政策有疑问，或希望删除与本扩展相关的数据，请联系 [邮箱]。

6. 政策更新：本政策更新后将在本页面公布，重大变更会在扩展更新说明中提示。

几个实操要点：第一，隐私政策必须有一个公开可访问的 URL，GitHub 仓库里的 PRIVACY.md 渲染页、Notion 公开页、自己的域名都可以，别用需要登录才能看的链接；第二，Chrome 的提交表单里除了政策链接，还有"数据用途披露"问卷，问卷答案必须和政策正文一致，问卷说"不收集"、政策里写"可能收集"，直接触发人工复核；第三，Firefox 这边 2025 年 11 月起新提交强制要求 manifest 里声明 data_collection_permissions，什么都不收集就声明 "none"，别留空让审核员猜。

什么时候必须认真写、不能套"零收集"模板？三种情况：扩展要登录（哪怕只是存个 token）、调用了自家或第三方的网络接口、用了崩溃上报或统计 SDK。每多一种数据流向，政策里就多一段对应的说明。记住审核员的视角：他不是在审你的文笔，是在做"声明 vs 代码行为"的交叉验证。代码里有一个 fetch 是政策里没提的，就是一封拒信。

五、商店页物料 SOP：截图、宣传图与描述文案

商店页是扩展的"门面"，也是 vibe coder 最容易敷衍的一环：代码写了一个月，截图随便截两张、描述写三行就提交。审核倒不一定因为这个拒你，但转化率会替你付出代价。下面是按"提交不被卡、用户愿意点"两个标准整理的 checklist，一次备齐。

图片物料：尺寸是硬门槛

• 商店图标 128×128 PNG：必填。同时准备 16/48/128 三档扩展图标（manifest 里引用），别拿一张大图缩放凑数，工具栏上糊成一团是最掉价的。
• 截图：Chrome Web Store 要求 1280×800 或 640×400，至少 1 张、最多 5 张；Edge Add-ons 接受 1366×768 / 1920×1080 / 2560×1440。截图顺序就是叙事顺序：第 1 张必须是"这个扩展是干什么的"一目了然的图，后面再放设置页、细节功能。
• 宣传图（可选但强烈推荐）：小图块 440×280、大图块 920×680、横幅 1400×560。有了它们，你的条目才有资格出现在商店首页推荐位和分类横幅里，流量差一个量级。

文案物料：短描述决定点击率

• 短描述 / 摘要：Chrome 限制 132 字符，AMO 的 summary 限制 250 字符。这是搜索结果页和列表页唯一显示的文案，写法是"动词 + 对象 + 场景"，例如"一键把任意网页正文抽成干净的 Markdown，粘贴即用"。别写"一款强大的生产力工具"——"强大"是最便宜的形容词。
• 长描述：讲清三件事——解决什么问题（用户视角）、怎么用（三步以内）、隐私承诺（一句话：数据只存本地/不收集）。vibe coder 常犯的错误是把长描述写成更新日志，满屏"v1.2 新增"，用户不关心你的版本号，关心"这东西能替我省什么事"。
• 分类与语言：分类选最贴近的那一个，别贪多选"全都沾边"的；语言按你的目标用户填，中文扩展就老老实实填中文，别为了"国际化"填英文然后描述里全是中文。

AI 生成截图的可用边界

这条必须单拎出来说，因为 vibe coder 手里 AI 生图太顺手了。商店截图必须是真实产品界面：审核政策禁止误导性展示，一张"看起来很美但产品里根本不存在"的 AI 截图，轻则被要求替换，重则按"欺骗性陈述"下架。可用边界是：截图本身必须是从真实运行的扩展里截出来的；允许的后期处理限于裁剪、标注箭头、打码隐私信息；宣传图（440×280 那种图块）的背景、配色可以用 AI 生成，但主体功能展示仍建议用真实界面。一句话：AI 可以美化表达，不能虚构事实。列表图的目标永远是让用户一眼看出这个扩展是做什么的——真实界面本身就是最好的广告。

六、审核被拒急救包：申诉信、对照表与时间线

先给一颗定心丸：被拒是常态，不是事故。第一次提交一次过的扩展是少数，大多数人都要经历 1–2 轮驳回。关键不在于"不被拒"，而在于被拒后 48 小时内做出正确反应：看懂拒信、改对地方、用对通道。下面三件套就是干这个的。

第一步：读懂拒信——常见驳回原因对照表

拒信关键词	真实意思	修复动作
权限 / permissions 过度	你要的比你用的多（见第三节）	收敛 permissions 与 host_permissions，补上每项的 justification，重新打包提交
远程代码 / remotely hosted code	包里有运行时从网络加载执行的代码	全部依赖本地打包，删掉 CDN 引用、动态 import、eval；这是红线，没有申诉空间，只能改
单一用途 / single purpose	扩展干了好几件不相干的事，或描述的功能与实际不符	砍掉边缘功能或拆分成多个扩展；描述严格按实际功能重写
隐私政策缺失或不符	没给政策链接，或政策说的和代码做的不一致	按第四节模板重写政策，保证"问卷 = 政策 = 代码行为"三处一致
误导性描述 / deceptive	截图或描述展示了产品没有的功能	替换为真实截图，重写夸大措辞；AI 生成的"概念图"全部下掉
混淆代码 / obfuscated code	代码可读性太差，审核员看不懂（Firefox 尤其严）	提交未压缩版本；AMO 要求混淆/压缩代码必须另交源码包

第二步：决定走"修复重交"还是"申诉"

决策树只有两层：拒信指出的是否属实？属实 → 别申诉，修完重交，这是最快的路，Chrome 重审通常 1–3 天；你确信是误判（比如审核员没理解某个功能的使用场景）→ 走申诉。注意 Chrome 的申诉通道（One Stop 支持表单）每个违规事项只有一次申诉机会，写申诉信之前先把证据备齐：功能演示录屏、权限使用的代码位置、测试步骤说明。申诉信模板如下，英文写，控制在 200 词以内，审核员每天看几百封，长的没人看：

Subject: Appeal regarding [Extension Name] (Item ID: [32 位条目 ID]) – [违规事项，如 Permission justification]

Hi review team,

Our extension [扩展名] was rejected for [拒信原文的违规事项]. We believe this was a misunderstanding, and here's the context:

1. What the feature does: [一句话功能描述，例如：the extension summarizes the current tab only when the user clicks the toolbar button.]

2. Why the permission is needed: [权限与功能的对应关系，例如：activeTab is the only host access used; no broad host permissions are requested.]

3. How to verify: [三步以内的复现路径，例如：1. Install the extension 2. Open any article page 3. Click the extension icon – the summary appears in the popup. No data leaves the browser.]

We've also attached [a 60-second demo video / screenshots] demonstrating the above. Happy to provide any further information.

Thanks,

[你的名字] ([联系邮箱])

申诉信的铁律：不抱怨、不讲情怀、只给证据。"我们是独立开发者很不容易"这种话对审核员是噪音；"第三步点这里能看到权限只在用户点击时生效"才是信号。如果申诉被驳回，不要反复申诉同一事项——回到"修复重交"路线，按拒信字面意思改到审核员挑不出毛病为止。

第三步：二次提交时间线

修复重交的全流程排个时间线，心里有数就不慌：Day 0 收到拒信，当天读懂并定位问题；Day 0–1 改代码/改文案/改政策，重新打包并在本地走一遍完整测试；Day 1 重新提交，附上 reviewer notes 说明"这次改了什么、对应拒信的哪一条"——这条备注很多人不写，其实它能显著降低第二轮被误伤的概率；Day 2–4 等结果，Chrome 重审通常 1–3 天，Edge 类似，AMO 可能稍长。注意一个坑：不要在没改任何东西的情况下点"重新提交"，系统会直接打回，浪费一轮排队时间。如果连续两轮被拒且理由在变，说明审核员是换着人在看——停下来，把 manifest、描述、政策、截图四件套全部按本文的 checklist 重新过一遍再交，第三次提交前找个同行帮你看一眼，旁观者最容易发现"当局者迷"的过度权限。

七、发版后最小动作：灰度发布与评价维护

上架只是起点。扩展一旦装进用户的浏览器，每一次更新都是一次"不可撤回"的推送——vibe coder 最容易在这里翻车：本地测得好好的版本，全量推送后才发现某个 Chrome 小版本上有兼容问题，回滚还得再走一轮审核。所以发版后的动作可以很少，但必须有：灰度，和评价维护。

灰度发布：Chrome 给了你刹车片，要用

Chrome Web Store 支持分阶段发布（staged rollout）：新版本先推送给一部分用户，观察几天没问题再全量。控制台里发布时选按比例发布，从 10%、25%、50% 逐级往上加。注意一个门槛细节：通过 API 按百分比精细控制（deploy percentage）要求条目有 10,000 以上的 7 日活跃用户，小扩展用控制台的手动分阶段就够了。灰度期间盯三件事：崩溃率有没有抬头（控制台的用户反馈与统计）、核心功能在真实环境下的表现、有没有收到"更新后不能用"的评价。发现问题直接暂停 rollout，修完再发——这比全量翻车后写道歉信便宜得多。Firefox AMO 没有灰度机制，批准即全量推送，所以 Firefox 版本的发版前测试要更保守：先在本地用临时加载跑透，再提交。

用户评价：每一条差评都是一次免费的用户访谈

商店评价是扩展唯一的公开反馈通道，维护它的 ROI 高得离谱：第一，差评必回。用户给一星多半是因为某个具体 bug 或误解，回复里给出 workaround 或"已在 x.y.z 修复"，很多用户会回来改分；不回复的差评会一直挂在那里劝退新人。第二，把评价当需求池。vibe coder 做扩展最缺的不是实现能力，是"下一个版本做什么"的判断——评价区里重复出现两次以上的诉求，就是下个版本的候选。第三，在更新说明里回应用户。"感谢 @xxx 反馈的 XX 问题，本版本已修复"——写进更新日志的用户，会变成你最忠实的传播者。第四，别买评价、别刷好评，三家商店都有反作弊机制，抓到就是下架，比差评严重一百倍。

最后，把发版后的最小动作固化成一个月度节奏：每月看一次控制台的安装/卸载/评价数据，每月发一个"修 bug + 回应评价"的版本。扩展和 App 不一样，它没有"冷启动红利"，增长来自口碑和搜索排名，而这两样都奖励"持续维护"的条目。一个三年里每月都更新的扩展，和一个三年没动的扩展，在用户眼里根本不是同一个物种。

写在最后：一张上架前的终检清单

把前面 7 节压缩成一张清单，提交前逐项打勾。manifest 里没有零引用的权限；host_permissions 收敛到最小域名集合；zip 里没有任何运行时加载的远程代码；popup/options 页没有内联事件处理器；service worker 的状态走 storage、定时走 alarms；隐私政策 URL 公开可访问，且"问卷 = 政策 = 代码行为"三处一致；截图是真实界面、第一张一眼能看懂；短描述 132 字符以内讲清价值；reviewer notes 写了测试路径。打完勾再点提交——审核这道坎，九成是自己人生的。

从 zip 包到商店页，真正的门槛从来不是技术，是"用审核员的视角看自己的产品"。vibe coding 让你一周做出扩展，上面这 7 道坎决定它能不能活过第一年。祝上架顺利，评论区见。