这段旅程
1
注册商店账号
每个商店都要求先有开发者账号，其他事情才谈得上。费用、协议以及各商店要求的注册流程，见下方的
账号前置条件。
2
每个 listing 都先手动创建一次
Chrome 和 Edge 的 API 无法创建新的 listing。第一个 zip 要在商店后台手动上传。
正是这次首传创建了自动化所需要的扩展 ID（Chrome）和 Product ID（Edge）。
Firefox 可以通过 API 创建新的 unlisted 附加组件；listed 附加组件仍然需要一次手动首提。
3
逐个商店拿到 API 凭据
照着上面链接的各商店指南做。每份指南都会点名具体的门户页面、展示每个值长什么样，并列出过期规则。
4
填入凭据
在你自己的 CI 中设置环境变量，或者把它们放在一个你自己写的
.env.submit 文件里。
别让它进 git。5
编写 STORE.md
在第一次提交之前先写好 STORE.md 元数据文件。
提交工具会读取它，并自动附上审核者备注、发布说明和认证说明。没有它，提交出去就是不带任何备注的。
6
提交
从你自己的 CI 对着各商店的 API 提交。工具支持时先跑一次 dry run：
dry run 会校验凭据并打好 zip，但不上传任何东西。
7
跟踪审核
提交成功只代表商店接受了这次上传并把它排进了审核队列。审核是第三方的决定：
轮询各商店的后台或 API 获取状态，在商店确认之前，绝不要宣称某个 listing 已经上线。
8
处理被拒
读懂商店返回的失败原因，修掉根因，并把两者都记进
STORE.md 的版本历史部分，
这样下一次提交就不会重蹈覆辙。含糊其辞的权限说明，是每个商店上最常见的被拒原因。账号前置条件
凭据放在哪里
凭据由你自己保管。.env.submit 文件是常见的按项目存放凭据的方式：
每个仓库一份，不进 git，背后由你自己的密钥存储托底。在 CI 中，把每个值都存成 secret。
即使两个项目共用同一个商店账号，也要按项目分开保管凭据。
三个商店的 API 凭据都是账号级的，所以在商店这一侧，为每条产品线单独开一个发布者账号，
才是唯一真正的隔离边界。这样轮换一个凭据就只会影响一个项目。
各商店提交需要什么
下一步
- 拿到凭据：Chrome、 Firefox、 Edge。
- 把这些书面材料写一次就够： 用一个 STORE.md 文件管理商店元数据。