自动化提交 Firefox Add-ons（AMO）需要一对凭据，并且在大多数情况下还需要一个标识符：
前置条件
- 创建一个 Firefox 账号，并在
addons.mozilla.org 登录。
- 接受 Firefox Add-on Distribution Agreement。在你接受之前，API key
页面一直是锁着的——哪怕这个账号已经通过网页界面发布附加组件很多年了。
生成 API 凭据
- 打开
AMO API key 页面。
- 生成新的凭据。
- 复制 JWT issuer。它的形式是
user:12345678:987。多数工具口中的
API key 指的就是这个值。
- 立刻复制 JWT secret。
JWT secret 只会显示一次。如果你弄丢了它，就只能重新生成一对凭据，而这会让旧的那一对在所有正在使用它的地方失效。
附加组件 GUID 与首次提交
GUID 的规则取决于发布渠道：
- Listed（在 AMO 上公开上架）：必须已经有一个 GUID。请先在
开发者中心 手工完成首次提交，
之后再自动化后续更新。
- Unlisted（签名后自行分发）：首次提交时把 GUID 留空，AMO
会创建一个新的附加组件并分配 GUID。
留空 GUID 这个便利只有一次机会，而且没有任何东西会帮你把分配到的 GUID
写回去。首次 unlisted 提交之后，请到开发者中心打开这个附加组件的页面，复制分配到的
GUID，并保存到你的 store 配置里。之后每一次 GUID 为空的提交都会再创建一个全新的附加组件，而不是更新第一个。
listed，结果要么失败（没有
GUID），要么发布出一个你未必想要的公开上架（设置了 GUID）。
新附加组件的 manifest 要求
新的附加组件必须在 manifest 中声明数据收集权限，否则 AMO 会拒绝这次提交：
自 2025-11-03 起，AMO 对每一次新提交都要求这个键。你不必等到上传时才发现被拒：当解析后的
Gecko manifest 缺少
browser_specific_settings.gecko.data_collection_permissions 时，面向 Firefox
目标的生产构建会发出警告。
只有当扩展确实不传输任何数据时才使用 ["none"]。这份声明、STORE.md
中的隐私章节以及代码三者必须一致。完整规则见
Firefox 商店就绪。
打包构建所需的源代码 zip
当上传的内容经过压缩或打包时，AMO 会要求提供源代码 zip——Extension.js
的生产构建正属于这种情况。用下面的命令生成：
请在 STORE.md 的审核者说明章节里讲清楚如何从源代码构建。
影响范围与轮换
AMO API 凭据是账号级别的。这对 issuer 与 secret
可以上传到你账号控制下的每一个附加组件。如果你为多个客户管理附加组件，请把每个客户的附加组件放在该客户自己的
AMO 账号下。
名称对照
每个值对应的环境变量：
