Chrome Web Store 扩展入驻与审核指南：从注册到上架一次讲清

Chrome Web Store 扩展入驻前，先抓住审核重点

如果要把网页效率工具、页面增强工具，或者基于 Manifest V3 的浏览器 Agent 上架到 Chrome Web Store，先别急着打包上传。审核真正看的，不只是功能能不能用，而是权限是否合理、代码是否合规、隐私披露是否真实。

简单说，想提高通过率，就要先把三件事做好：

• 扩展只做一件明确的事，别把功能做得太杂。
• 权限申请尽量少，能用 activeTab 就别直接上来就要 tabs 或 。
• 如果涉及 chrome.debugger、云端 AI 或网页内容上传，隐私政策必须和代码行为一致。

上架流程怎么走

Chrome Web Store 的完整流程并不复杂，但每一步都要准备到位：

• 注册开发者账号并完成邮箱验证。
• 开启 Google 账号两步验证。
• 准备 Manifest V3 扩展包，ZIP 根目录必须有 manifest.json。
• 清理无用文件，移除密钥、.env、日志和测试数据。
• 准备隐私政策、官网、支持页面和商店截图。
• 填写 Privacy、Distribution、Test instructions。
• 提交审核，等待通过后发布。

建议把发布邮箱单独设置成长期可用的团队账号，例如专用发布邮箱。因为后续审核通知、拒绝原因、政策警告，都会发到这个邮箱，绑定后也不适合随意更换。

Manifest V3 和包体结构，决定了基础分

Chrome 当前对新扩展基本按 Manifest V3 标准来审。上传包时，最容易出问题的地方有两个：一个是版本不对，另一个是目录结构不对。

正确做法是把最终构建产物压缩成 ZIP，且 manifest.json 直接放在根目录。比如：

extension.zip
├── manifest.json
├── service-worker.js
├── popup.html
├── popup.js
├── content-script.js
├── icons/
└── assets/

不要把整个项目文件夹再套一层压进去，否则审核时很容易识别失败。

另外，最终提交的包里不要残留开发内容，例如：

• .git、.env、测试账号密码
• 未使用的大型依赖
• 内部调试日志
• 私有服务器地址和证书文件

提交前最好单独跑一次生产构建，只上传 dist 目录内容。这样更干净，也更符合审核习惯。

权限申请要遵守最小原则

Chrome 审核里最常见的拒绝原因之一，就是权限申请过宽。很多扩展明明只服务当前页面，却一次性申请一堆高危权限，结果审核员一眼就会质疑。

更稳妥的思路是按需申请：

• 只读取当前页面时，优先用 activeTab。
• 需要注入脚本时，再配合 scripting。
• 需要保存设置时，用 storage。
• 只有确实要调试标签页、控制页面时，才申请 chrome.debugger。

如果扩展只支持特定站点，host_permissions 也尽量写精确域名，不建议一上来就写 。只有当产品确实是跨站网页助手、并且用户主动授权后才在不同站点工作，才有理由使用更广范围的权限。

远程托管代码是高频雷区

很多扩展被拒，不是功能不好，而是出现了远程托管代码。Chrome 对这一点很敏感，尤其是 Manifest V3。简单理解就是：扩展要执行的代码，应该在安装包里，而不是运行时从服务器拉下来再执行。

高风险写法包括：

• 运行时 fetch JavaScript 再 eval 执行。
• 直接引用远程 CDN 的脚本。
• 让服务器返回字符串代码，再交给 Runtime.evaluate 执行。

更安全的方式是：云端只返回结构化数据，比如动作指令、页面摘要、状态结果，真正执行动作的逻辑放在本地扩展包中。也就是说，模型决定“做什么”，本地执行器决定“能不能做”。

如果是 AI 浏览器 Agent，这一点尤其重要。不要让模型直接生成任意 JavaScript，更不要把模型返回内容当代码执行。

chrome.debugger 类扩展，审核会更严格

涉及 CDP 或浏览器自动化的扩展，审核会比普通工具更谨慎，因为 chrome.debugger 能做的事情比较多，例如查看网络、读 DOM、控制页面、修改内容等。

这类扩展最重要的原则是：用户主动启动，任务结束立即断开。

• 必须由用户点击“开始任务”或类似按钮后再连接标签页。
• 只连接用户明确选中的当前标签页。
• 操作范围要可见、可控、可停止。
• 任务完成后一定要 detach。

建议把动作限制在白名单里，例如点击、输入、滚动、导航、截图、读取页面摘要这些基础操作。不要开放任意 JS 执行，否则会被视为高风险设计。

对于提交表单、发送消息、删除内容、下载文件、支付、改密码这类动作，最好再加一次用户确认。这样既能减少误操作，也更容易通过审核。

隐私政策要和真实行为完全一致

如果扩展会读取网页正文、表单内容、截图、URL，或者把数据发到云端 AI 服务，那么隐私政策就不能只写一句“我们不收集数据”。Chrome 要求商店声明、隐私政策和代码行为三者一致。

隐私页至少要写清楚这些内容：

• 收集了哪些数据。
• 什么时候读取数据。
• 数据用于什么功能。
• 是否发送到自家服务器。
• 是否发送到第三方 AI 模型服务商。
• 保存多久，用户如何删除。
• 是否用于训练模型。
• 是否会被人工查看。

如果你的网站确实把页面内容发往云端处理，就要明确说明这一点。最怕的就是页面写一套，实际代码跑另一套，这会直接拉低审核信任度。

商店资料怎么写更容易过审

扩展名称要短、准、清楚，不要堆一长串关键词。比如与其写成“Best AI Browser Extension Assistant Tool”，不如直接写成产品真实用途相关的名字。

摘要部分要控制在 132 字符以内，核心就是一句话说清扩展能做什么。描述部分建议采用“功能 + 权限 + 数据说明”的结构，方便用户和审核员快速理解。

截图也很关键，最好用真实产品界面，至少准备 3 到 5 张，内容可以包括：

• 用户启动任务的界面。
• 系统展示操作计划的界面。
• 页面元素识别过程。
• 高风险操作确认页。
• 任务完成结果页。

Test instructions 不要省

很多扩展不是技术不过关，而是审核员根本没法测试。尤其是需要登录、订阅、特殊权限、测试页面的产品，最好在 Test instructions 里写得非常清楚。

推荐提供：

• 一个可长期使用的测试账号。
• 清晰的安装步骤。
• 明确的操作路径。
• 哪些页面可测试，哪些功能是审核必看。

如果核心功能必须依赖 AI 服务，也要保证审核期间可用，别让配额耗尽或接口失效，否则很容易卡在 Pending Review。

常见拒绝原因，提前避开最省时间

从实际审核经验看，拒绝原因通常集中在这几类：

• 权限过多，和产品功能不匹配。
• 存在远程加载脚本或 WASM。
• 单一用途不明确，功能太杂。
• 隐私声明和真实行为不一致。
• 审核账号失效、测试步骤不清楚。

想稳一点，第一版建议走保守路线：Manifest V3、最小权限、用户主动启动、当前标签页、固定动作白名单、高风险操作确认、任务结束自动断开。等首版稳定后，再逐步增加新能力。

最后的发布建议

如果目标是提高 Chrome Web Store 首审通过率，最实用的办法不是“包装得更像”，而是“做得更清楚”。把功能边界、权限理由、数据流向、测试方式都说明白，审核通常会轻松很多。

一句话总结：Chrome Web Store 上架不是拼功能多，而是拼合规、清晰、可验证。把基础资料做扎实，比盲目加功能更重要。