扩展商店审核被拒这条路：manifest v3 的权限最小化，和那封申诉信

把一个目录站塞进浏览器扩展，入口价值是实打实的：新标签页、工具栏按钮、右键菜单，都能把用户拉回分类页。问题是这条路的最后一关不在你手上。

商店审核里被拦下的扩展，绝大多数和技术难度无关。常见原因排下来是这几类：权限与功能不匹配、元数据缺失或夸大（描述的功能和实际上线的不一致），以及干脆缺了图标、截图、说明。

图片来源：网络，版权归原作者所有，侵权请联系删除

先分清四个抽屉

Manifest V3 把权限拆得更细，这个拆分本身就是审核的依据：

字段	装什么	审核视角
permissions	API 能力，如 storage、alarms	逐条看有没有对应调用
host_permissions	对哪些站点生效	越宽越容易被人工审
optional_permissions	运行时再申请	用户点开时再申请
activeTab	用户主动触发才拿到当前页	多数场景的正确替身

官方那条「Use of Permissions」政策的意思很直白：实现功能所需的、访问范围最小的那一个；如果两种权限都能做到同一件事，选能触及更少数据的那个；不许为了将来可能要上的功能提前申请权限——这一条被明确写出来，说明真有人这么干。

被判「过度」最常见的三种

该用 activeTab 却用了 tabs

只读当前标签页的 URL 和标题，用 activeTab 配合用户点击就够了。tabs 权限关注的是「任意标签页的敏感数据」，很多扩展其实只用到了它很小一部分能力，却整条申请下来。

把 cookies 当 localStorage 用

纯配置、偏好、草稿，走 Web 存储或 IndexedDB 就行，不必碰 cookies 权限。反过来也一样：真要读 SameSite 这类细节，才该动 chrome.cookies。

为了省事申请全部站点

只需要在三四个域名下工作的扩展，写具体匹配模式。宽泛主机权限不仅仅增加审核时间，安装时那句提示也会劝退用户。

拒稿邮件怎么写，你该怎么回

驳回通知通常会引用具体政策条款。处理的顺序是：

邮件说的是	正确动作	不要做
某权限代码中未使用	从 manifest 删掉那一行的三个数组	写长文解释留着的价值
权限超出功能所需	降级到更窄的替身	补一段更长的理由
元数据不足或有误导	补齐图标/截图/描述，说清功能	只改标题加关键词
疑似远程代码或混淆	移除外部脚本加载，保留可读代码	解释为构建工具产物

顺带提醒一句：MV3 下远程托管然后在运行时执行，这条是硬红线，压缩可以，混淆基本等于自找麻烦。

什么时候申诉，而不是改

申诉不是让对方再想想。只有当你确信审核方的判断基于事实错误时，申诉才有意义——比如确实被调用了，只是调用路径在打包后的代码里不明显。官方也说明一次违规决定通常只有一次申诉机会，别把它当成拖延的手段。

申诉信四块内容，写完就该收手：

第一，引用邮件里那一条政策原文（原样引用，不要 paraphrase）。

第二，指出具体的权限名、文件名或行为。

第三，用两句话说明这个权限对应哪一个用户可见的功能。

第四，版本号 + 你做了什么改动（如果改了的话）。

语气保持陈述事实。审核队列很长，短的、带证据的申诉比长的、带情绪的通过率高得多。

提交前那十分钟值得省麻烦

把 manifest 里每一行权限对一遍代码调用，删掉没人用的；确认图标、至少一张截图、说明文字都齐了；涉及任何用户数据就把隐私政策和数据处理勾选表填完整——勾错了和处理错了后果一样。

还有个反直觉的细节：已上线的扩展再增加权限，代价远高于首发就把权限谈清楚。因为一旦在一次更新里增加了权限，已经安装的用户会被浏览器停掉并弹确认，很多人不会点那个「重新启用」。所以权限清单要按长期的样子设计，别指望以后慢慢加。

最后一句实话：审核时长官方不给承诺，权限窄、无远程数据收集的常见天数内出结果，碰到宽权限的人工审查拖到几周也正常。发布计划千万别建立在「明天就能过」的假设上。