Chrome Web Store 发布
本教程共 56 篇 · 第 48 篇 · 更新于 2026-08-13 · 约 9 分钟阅读
本节目标：学完你能注册开发者账号、把扩展正确打成 zip 包、填好商品详情并提交审核，最终让 MV3 扩展在 Chrome Web Store 上架。
代码写完了、本地 Load Unpacked 也跑通了，下一步就是让别人也能装上。Chrome Web Store（Chrome 网上应用店）是目前用户量最大的扩展分发渠道。
这一节专门讲怎么把你的 MV3 扩展送上架，从账号到提审一步步走完。
48-1 上架前先确认三件事
动手之前把三个前提钉死，不然后面会反复返工。
第一，你的扩展必须是 Manifest V3。清单里 manifest_version 写成 3 是唯一标准，写别的值提审时会被直接拦下。
第二，扩展不能包含远程托管代码。所有逻辑都要打进包里，不能在运行时从服务器拉脚本执行。这条红线在前面讲过，发布环节审核会重点查。
第三，功能自测要过。用开发者模式完整跑一遍，把控制台报错清零。审核人员真会点开用，带着一堆红色报错上架很容易被拒。
Note提审前也顺手检查一下
permissions。用不到的权限现在删掉，比过审后再解释省事得多。
48-2 注册开发者账号
打开 Chrome Web Store 开发者控制台（Developer Dashboard），用你的 Google 账号登录。
- 第一次进入会让你接受《开发者协议》。
- 接着要交一笔一次性开发者注册费，金额以官网当期公示为准。这一步是身份校验，交一次长期有效，不是按扩展收费。
- 按要求完成两步验证。现在账号必须开启两步验证才能发布，别想着跳过。
账号类型分个人和企业。个人用自己的 Google 账号即可；代表公司发布就用公司账号，并补全商家资料，后续开票、转移所有权都顺畅。
Tip注册邮箱最好选团队能接管的邮箱。绑死在某个员工的私人账号上，人一离职扩展所有权就麻烦了。
48-3 把扩展打成 zip 包
上传的是 zip 包，不是整个工程目录。这里有个高频坑：zip 的根目录必须直接是 manifest.json，不能多套一层父文件夹。
假设你的扩展目录叫 my-ext，正确结构是这样：
my-ext/
manifest.json
background.js
popup.html
popup.js
icons/
icon16.png
icon48.png
icon128.png打包时先进入 my-ext 目录，再把里面的全部文件压缩：
# 进入扩展目录后打包，确保 manifest.json 在 zip 根
cd my-ext
zip -r ../my-ext.zip . -x "*.DS_Store" -x "*.map"别在上级目录执行 zip my-ext.zip my-ext/。那样解压出来会多一层 my-ext/，商店读不到清单，上传直接失败。
Windows 用户也可以直接用资源管理器：进入目录、全选文件、右键压缩。关键仍然是「选文件，不选文件夹」。
打包之前记得清掉这些不该上传的东西：
node_modules/、构建缓存、源码映射.map文件- 本地测试脚本、多余的说明文档、
.git目录 - 任何含密钥或私有配置的文件
图标要齐全。清单里 icons 引用的每个尺寸都得有对应文件，其中 128×128 是商店展示用的主图标，缺了会提审失败。
{
"manifest_version": 3,
"name": "我的扩展",
"version": "1.0.0",
"description": "一句话说清这个扩展干什么",
"icons": {
"16": "icons/icon16.png",
"48": "icons/icon48.png",
"128": "icons/icon128.png"
}
}Note商店对包体大小有上限（以官网当期为准）。体积异常大时先检查，多半是误把依赖目录或压缩包打了进去。
48-4 扩展 ID 是怎么来的
本地加载时，扩展 ID 由目录路径推导，换台机器就变。上架之后，商店会给你分配一个固定的 32 位扩展 ID，从此不再变化。
这个 ID 很关键。它决定了 chrome-extension:// 资源地址、OAuth 回调白名单、以及自托管更新的匹配关系。所以：
- 开发阶段别把 ID 写死进代码，用
chrome.runtime.id动态取。 - 上架之后再去补白名单一类的外部配置，此时 ID 才稳定。
// 取当前扩展的 ID 和版本，不要硬编码
const id = chrome.runtime.id;
const version = chrome.runtime.getManifest().version;
console.log(id, version);Tip清单里可以放
key字段来锁定本地开发时的 ID，但这属于进阶做法。初学阶段直接用chrome.runtime.id就够。
48-5 填写商品详情
上传 zip 后，控制台进入「商品详情」编辑页。这一页决定用户在商店里怎么看你的扩展，别填得太随便。
主要必填项有这些：
- 名称：简短好记，和清单里的
name风格保持一致。长度有上限，堆关键词会被判违规。 - 摘要：一句话说清能干嘛，会出现在搜索结果里。
- 详细描述：讲清功能、使用场景、每个权限的用途。用户最在意「你要我的权限干什么」，说清楚能少很多差评。
- 语言：选主要语言。多语言可配
_locales，前面国际化一章讲过。 - 图标与截图：128 图标必备，另配一到两张功能截图。截图要真实展示界面，别放纯文字海报。
- 分类：选最贴近的一个类别，别乱选热门分类蹭流量。
Tip权限申请得越多，描述里越要解释清楚。审核会逐条看
permissions是否合理，含糊其辞容易被打回补充说明。
48-6 数据用途与隐私政策
控制台里有一块「隐私」相关的表单，需要你逐项勾选扩展会处理哪类数据，并声明用途。
只要扩展收集或处理用户个人数据，哪怕只存在本地，也必须提供隐私政策链接。这个链接要能公开访问，内容要和你勾选的项目对得上。
同时还要确认几条使用声明：数据不出售、不用于无关用途、不做与主功能无关的采集。这些勾选是有约束力的承诺，别随手点过。
Note声明和实际行为不一致，是被下架的常见原因之一。功能变了记得回来同步改声明。
48-7 选择可见范围
提交前要确定扩展的可见性，三种模式想清楚再选：
- 公开：所有人都能搜到并安装，最常见的选择。
- 不公开：有链接才能装，不出现在搜索和分类里。适合内测或给特定客户用。
- 私有：仅限你指定组织内的用户，通常用于企业部署。
多数个人开发者选公开就够。只想给一小拨人用的话，先用不公开试水，打磨好了再转公开。
48-8 上传提审
详情填完，点「提交审核」。流程大致分三步：
- 自动扫描：系统先跑一遍，检查包结构、清单合法性、有无违禁代码、权限是否超标。这一步通常几分钟内出结果。
- 人工审核：自动检查过了才进人工队列。时长不固定，快则一两天，慢则一周以上，节假日更久，官方没有承诺硬工期。
- 结果通知：通过后自动上架；被打回会附带原因，按提示改完重新提交。
提交后状态变成「待审核」，进度能在控制台随时看到。耐心等，频繁催没有用。
Note第一次提审通常比后续更新慢，因为审核员要完整评估整个扩展。之后的版本更新一般快很多。
48-9 常见被拒原因
提前知道这些坑，能省掉好几轮返工：
- 功能与描述不符：描述写「一键翻译」，实际只做了书签管理。
- 权限过度申请：申请了
history却根本没用到，或用途说不清。 - 违反单一用途：一个扩展塞进多个毫不相关的功能，会被认为意图不明。
- 包含远程代码：运行时拉取并执行外部脚本，直接触碰红线。
- 品牌侵权：图标、名称蹭知名产品，未授权使用商标。
- 占位或敷衍内容：截图是空白页、描述是乱码，一眼看出没认真做。
被拒别慌，控制台给出的原因就是修改指南。改完在回复说明里把对应项讲清楚，重新提交即可。
48-10 小结
Chrome Web Store 上架的动作串起来是：注册开发者账号（一次性费用加两步验证）→ 打包 zip（manifest.json 必须在根，清掉依赖和密钥）→ 填商品详情（名称、描述、截图、128 图标、分类）→ 完成数据用途与隐私政策声明 → 选可见性 → 提交审核 → 通过上架。
全程只接受 MV3，且不得含远程代码。扩展 ID 上架后才固定，代码里用 chrome.runtime.id 动态取。被拒是常事，按原因改、说明清楚再提交就行。下一节讲 Edge 和 Firefox 怎么发。