poxiaoxi博客浏览器插件在本地开发完成后，可以通过Chrome的“加载已解压的扩展程序”进行测试，但这种方式并不适合正式分发。如果希望普通用户点击链接后直接安装，并让后续版本自动更新，通常需要把扩展程序发布到Chrome Web Store。
上架过程本身并不需要把项目重新开发一遍，但Chrome Web Store关注的不只是插件能不能运行，还会检查权限、用户数据、远程代码、商店描述以及扩展程序实际功能是否一致。因此，一个本地能够正常运行的插件，并不代表把文件压缩上传后就一定可以通过审核。
上架前先确认插件能正常运行
正式提交以前，最好先在Chrome本地完整测试一次最终准备上传的版本。
可以打开：
chrome://extensions/
开启“开发者模式”，选择“加载已解压的扩展程序”，加载自己的项目目录，然后检查插件的主要功能。
测试时不要只确认弹窗能不能打开，还需要根据实际功能检查内容脚本、Service Worker、快捷键、右键菜单、页面权限、跨域请求以及登录流程等。
Chrome官方也建议开发者测试实际准备提交的文件，而不是只测试开发环境中的另外一个版本。构建工具、文件路径和大小写差异，都可能造成开发环境正常、上传版本却无法工作的情况。
新插件需要使用Manifest V3
现在准备发布新的Chrome扩展程序，需要使用Manifest V3。Chrome Web Store已经不再接受新的Manifest V2扩展程序。
一个简单的manifest.json可能类似：
{
"manifest_version": 3,
"name": "My Extension",
"version": "1.0.0",
"description": "一个简单的Chrome扩展程序",
"action": {
"default_popup": "popup.html"
},
"permissions": [
"storage"
]
}实际项目当然可能复杂得多，但正式打包以前至少要检查几个基础字段，包括name、version、description和图标配置。
其中版本号尤其需要注意。以后每次上传新版扩展程序，都需要提高version，不能继续上传和上一版完全相同的版本号。
不要申请用不到的浏览器权限
权限是Chrome插件审核中非常重要的一部分。
例如插件可能在manifest.json中申请：
"permissions": [ "storage", "tabs", "contextMenus" ]
也可能申请网站访问范围：
"host_permissions": [ "https://example.com/*" ]
问题并不是“申请权限一定会被拒”，而是权限应该与插件实际功能匹配。Chrome官方要求扩展程序申请实现功能所需要的最低权限。
例如一个只负责保存用户界面设置的插件，如果申请访问所有网站：
<all_urls>
审核人员自然需要判断为什么这个功能需要读取这么广泛的网页内容。
提交时，Developer Dashboard的Privacy practices页面还会要求开发者解释部分权限的用途。因此，与其上传以后再想怎么解释，不如在开发阶段就删除实际上没有使用的权限。
Manifest V3不能随意执行远程代码
一些插件本地测试正常，上架时却遇到问题，原因可能不是功能本身，而是代码加载方式不符合Manifest V3要求。
例如下面这种从远程服务器直接加载JavaScript的方式并不符合Manifest V3的要求：
<script src="https://example.com/app.js"></script>
通过网络获取一段JavaScript字符串再使用eval()执行，也属于需要特别避免的做法。
Manifest V3要求扩展程序的功能逻辑能够从提交的代码中进行审核。插件可以请求API、下载数据或者读取服务器返回的内容，但不能把真正控制插件行为的可执行逻辑放在远程服务器上，再动态下载执行。
如果项目使用了CDN中的JavaScript库，上架前同样需要检查。很多情况下应把需要执行的库文件包含在扩展程序安装包中，而不是运行时从CDN加载。
注册Chrome Web Store开发者账号
代码准备完成后，需要使用Google账号进入Chrome Web Store Developer Dashboard并注册开发者账号。
Chrome官方要求开发者同意开发者协议并支付一次性注册费用。目前官方支持页面显示注册费用为5美元，这不是每年重复收取的订阅费用。
开发者账号还需要设置发布者名称并验证电子邮件。Google同时要求能够发布或更新扩展程序的开发者Google账号启用两步验证。
这里值得提前考虑账号归属。如果插件属于公司产品，通常更适合使用长期可管理的公司账号或团队发布体系，而不是完全绑定某位员工的私人账号。Chrome官方说明，开发者账号创建之后不能直接修改其账号电子邮件，后续如果需要更换所有者，需要通过扩展程序转移流程处理。
把插件目录打包成ZIP文件
Chrome Web Store上传的是ZIP安装包，不是直接上传整个Git仓库。
可以把真正运行扩展程序所需要的文件整理后压缩，例如：
my-extension/ ├── manifest.json ├── popup.html ├── popup.js ├── background.js ├── content.js └── icons/ ├── icon16.png ├── icon48.png └── icon128.png
压缩以后需要保证manifest.json位于ZIP文件的根目录。
错误结构通常是：
extension.zip └── my-extension/ └── manifest.json
更合适的是：
extension.zip ├── manifest.json ├── popup.html ├── popup.js └── icons/
也没有必要把开发过程中产生的所有文件都放进去。例如源代码仓库中的设计稿、测试文件、开发文档和其他与运行无关的内容，可以根据项目构建方式排除。
在开发者后台创建新项目
登录Chrome Web Store Developer Dashboard以后，可以选择添加新项目，然后上传刚才准备好的ZIP文件。
系统会先检查安装包和manifest.json是否能够正常解析。如果JSON格式错误、引用的文件不存在或者扩展程序本身存在明显安装问题，就可能在这一阶段直接提示错误。
2026年8月Chrome Web Store还加入了提交前安装测试。扩展程序上传到草稿后，会执行自动检查，确认安装包能否在支持的平台正常安装。这样一些基础问题可以在真正进入审核队列以前发现。
如果发现manifest.json里的名称、描述或者版本写错了，不能直接在商店后台修改安装包内部内容，需要修改源文件后重新打包上传。
商店页面需要准备哪些内容
上传ZIP只是创建了扩展程序项目，真正提交以前还要完成Store listing，也就是用户以后在Chrome Web Store看到的产品页面。
通常需要准备：
扩展程序名称和详细介绍；
产品分类和主要语言；
128×128像素的商店图标；
至少一张实际功能截图；
必要的宣传图片；
官方网站或产品主页，可根据实际情况填写；
用户支持页面，可根据实际情况填写。
官方推荐的扩展程序截图尺寸为1280×800，也支持640×400，最多可以上传5张。
商店介绍最好直接说明插件解决什么问题、如何使用以及提供哪些核心功能，不需要为了搜索排名大量重复关键词。Chrome Web Store明确限制关键词垃圾内容，宣传页面和插件实际能力也应该保持一致。
例如插件只是网页截图工具，就没有必要在描述中同时写成“图片编辑器、视频下载器、AI助手、SEO神器”等并不存在的功能。
Privacy practices是审核重点
Store listing完成以后，还需要填写Privacy practices，也就是隐私实践信息。
其中通常需要说明几个问题。
插件的单一用途是什么
Chrome Web Store要求扩展程序具有清晰、容易理解的单一用途。
这里的“单一用途”并不意味着插件只能有一个按钮，而是所有主要功能应该围绕一个清晰目标展开。
例如“帮助用户保存和管理当前网页中的图片”是比较容易理解的用途，而把网页截图、天气预报、加密货币行情、广告点击和标签页游戏全部塞到同一个插件中，就很难解释这些功能之间有什么共同目的。
为什么需要这些权限
后台会根据manifest.json显示插件申请的相关权限，开发者需要解释权限对应的功能。
权限说明最好具体。例如申请storage时，可以说明它用于在浏览器本地保存用户设置，而不是只写“插件运行需要”。
插件会收集哪些用户数据
如果扩展程序会收集或传输用户数据，需要按照实际情况披露数据类型以及用途。
如果涉及个人或敏感用户数据，还需要遵守Chrome Web Store对应的用户数据政策，并根据实际数据处理方式提供隐私政策。
这里最重要的是保持一致：代码实际行为、商店隐私声明和网站上的隐私政策不能互相矛盾。
选择公开还是链接分发
在Distribution页面可以设置扩展程序的分发范围。
| 发布方式 | 适用情况 |
|---|---|
| Public | 公开出现在Chrome Web Store，普通用户可以搜索和安装 |
| Unlisted | 不作为普通公开商店列表展示，通过知道商店链接的用户进行安装 |
| Private | 限制给指定用户或测试范围使用 |
如果插件还处于早期测试阶段，没有必要一开始就面向所有用户公开，可以先根据项目需求选择Private或Unlisted进行测试。
需要注意的是，不公开并不意味着可以绕过Chrome Web Store政策。官方明确说明，不同可见性设置仍然需要遵守相同的政策，并需要经过审核。
提交以后需要等待商店审核
商店信息、隐私信息和分发设置填写完成以后，就可以点击“Submit for Review”提交审核。
Chrome Web Store会进行自动审核，部分扩展程序还会进入人工审核。新开发者、新扩展程序、敏感权限、广泛的网站访问权限、大规模代码变更或者难以审核的代码，都可能增加审核所需要的时间。
因此网上经常看到的“Chrome插件固定几个小时审核完成”或者“固定三天一定通过”并不准确。审核时间会根据项目情况变化。
审核期间可以在Developer Dashboard查看状态。常见状态包括Pending、Published、Rejected和Taken Down等。
如果被拒绝，Google通常会通过开发者账号邮箱提供相应的违规信息。更有效的处理方式是针对具体原因修改代码、权限或商店资料，而不是不做修改反复提交同一个安装包。
审核通过不一定立即公开
提交审核时还可以决定审核通过以后是否自动发布。
如果选择自动发布，审核通过以后扩展程序会进入对应的发布状态。如果关闭自动发布，则可以先完成审核，再由开发者选择正式上线时间。
这种延迟发布方式比较适合需要同步官方网站、公告、产品文档或营销活动的项目。
官方目前规定，已经审核通过但处于待发布状态的提交，需要在规定时间内完成发布；如果超过期限，草稿可能需要重新提交审核。
插件以后怎么发布新版本
第一次成功上线以后，更新流程与首次提交相似，但不需要重新创建一个Chrome Web Store项目。
假设当前版本是：
"version": "1.0.0"
开发完成下一版以后，需要提高版本号，例如：
"version": "1.0.1"
然后重新生成ZIP，在现有项目的Package页面上传新安装包，再提交审核。
审核新版本期间，商店中已经发布的旧版本通常仍然可以继续供用户使用和安装。新版本审核通过并正式发布以后，Chrome会通过扩展程序更新机制向用户分发更新。
如果新版本新增了更高等级的权限，还需要考虑用户是否会看到新的权限提示，而不是默认认为所有更新都会静默完成。
当前发布数量也存在账号限制
Chrome Web Store在2026年8月调整了开发者扩展程序发布数量机制。现在发布上限会根据发布者账号情况动态确定，新机制下默认提供两个扩展程序发布名额。
已经拥有更多已发布扩展程序的账号不会因为这个变化直接下架现有项目。如果确实需要发布更多扩展程序，可以通过开发者后台申请提高限额。
这也意味着以前一些教程中提到的固定“最多可以发布20个扩展程序”已经不能简单作为当前规则使用，实际可发布数量应该以Developer Dashboard显示的账号额度为准。
上架前最容易忽略的几个问题
如果希望第一次提交时少走一些弯路，可以在上传前集中检查以下内容：
确认使用Manifest V3，而不是继续提交Manifest V2项目；
确认ZIP根目录直接包含
manifest.json；删除没有实际用途的权限和过于宽泛的网站权限；
不要运行Manifest V3不允许的远程JavaScript代码；
检查商店描述与插件真实功能是否一致；
准备清晰的实际功能截图，而不是只放宣传海报；
如实填写数据收集、权限用途和隐私政策；
涉及账号登录的插件，应保证审核人员能够理解如何测试核心功能；
提交前测试最终打包文件，而不仅仅是开发目录。
对于一个功能简单、权限较少的插件，上架流程实际上可以归纳为“本地测试 → 注册开发者 → ZIP打包 → 上传 → 填写商店资料 → 填写隐私信息 → 设置分发方式 → 提交审核”。真正容易造成问题的通常不是上传按钮本身，而是插件权限和隐私声明无法解释、代码使用了不符合Manifest V3要求的方式，或者商店页面描述与真实功能存在明显差异。
如果只是自己使用插件，没有必要为了本地安装专门上架Chrome Web Store；如果插件准备提供给普通用户长期安装和自动更新，再按照商店规则完成正式发布会更合适。对于准备商业化或长期运营的插件，也应该把权限、隐私政策和版本更新流程作为产品的一部分维护，而不是等到每次审核被拒以后再临时处理。
精彩评论