GitHub Marketplace 上架是一个分类型的提交流程：先取得验证发布者身份，再选定应用形态，配置最小权限与定价计划后提交审核。它的难点不在技术集成，而在权限申报的合理性与付费计划只能绑定在特定应用类型上。
对做开发者工具的团队来说，这个渠道的价值在于触达。仓库页面上的一次安装，比十条推广内容更有效，因为用户是在工作流里遇到你的。但上架的规则比想象中细，很多提交在审核阶段被退回，原因都不是功能问题。
GitHub Marketplace 上架是一个什么样的流程？
是一个「验证身份—选类型—配权限—定计划—提交审核」的五段流程。
验证身份是前置条件，平台要求发布者通过验证发布者（Verified Publisher）审核，核心是证明你拥有在描述里填写的域名。选类型决定后续能做什么：不同形态对应不同的计费方式与能力边界。配权限是技术环节，也是审核关注的重点。定计划只在付费上架时才有。提交审核之后进入人工核验，通过后获得展示位。
五段里最容易被低估的是第一段。没有验证发布者身份，后面的准备全部作废；而域名验证对一些用个人账号起步的开发者来说，本身就是一道门槛。
三种上架类型有什么区别？
GitHub App 能收费、Actions 按使用计费、扩展做对话集成。
GitHub App 是标准的应用形态，通过安装到仓库或组织来工作，可以申请细粒度的 API 权限、接收 webhook 事件，也是唯一可以绑定 Marketplace 付费计划的类型。做 SaaS 类工具、代码检查、项目管理集成的，基本都走这条路。
GitHub Actions 上架的是自动化流程，用户在 workflow 里引用。它的计费走 Actions 的运行分钟数体系，不适用 Marketplace 的订阅计划。适合做构建、测试、部署、扫描这类单点动作。
扩展形态面向对话式开发场景，把能力接进编辑器或对话界面。这类形态的门槛相对低一些，但对交互设计的要求更高——它不是把功能搬过来就行，得重新想一遍用户在对话里怎么用。
验证发布者要准备什么？
要能证明你拥有所填写的域名。
平台给发布者的展示信息里会带上域名，这个域名必须是你控制的。验证方式通常是通过 DNS 记录或指定路径的文件，个人账号与企业账号在流程上略有差异。
这条要求的作用是压缩冒名空间。没有它，任何人都能挂一个看起来像官方的域名做展示，用户无法分辨。所以即便技术上可以绕过，也不建议用近似域名的做法——审核会核对，而且用户会举报。
准备上架之前，先把这个域名背后的落地页做好。审核会看这个页面：它是不是在解释这个产品、有没有联系方式、有没有隐私政策。一个只有一句 slogan 的落地页，通常撑不过审核。
权限申报为什么决定审核速度？
因为权限越宽，审核越慢且越容易被拒。
应用需要申请哪几项 API 权限，是提交时逐项勾选的。平台对敏感权限（读私有仓库、管理组织成员、读写工作流）会重点核验：你为什么需要它、在什么场景下用、有没有更小的替代方案。
常见的退回情形是权限与实际功能不匹配。一个只做代码格式检查的应用申请了仓库管理权限，审核方会要求解释；解释不通，就会被要求缩减权限范围。缩减权限往往意味着要改代码，这一来一回就是几周。
正确的做法是在开发阶段就按最小权限设计，把功能拆到「只读某类资源」的粒度。权限申报不是填表，它是产品设计的一部分。 这与钉钉应用市场服务商入驻的审核逻辑相通：国内平台同样按权限范围与数据敏感度分级核验。
付费计划最容易踩的坑是什么？
以为填了价格就能自动收款。
Marketplace 支持两类付费计划：固定费率（按月或按年，按席位或按组织）与按量计费（per-unit）。固定费率相对简单，选了之后平台按订阅周期结算。按量计费则要求应用侧实现用量上报——你得在自己的系统里记录用量，并调用平台的接口把用量报上去，平台据此计费与分成。
不做这一步，用户装了付费版也用不了，因为系统里没有可结算的计量数据。
还有几个细节要提前想清楚：试用期怎么设、降级与取消时怎么处理已用量、退款政策怎么写、以及分成比例与结算周期（以官方文档为准，会调整）。这些不是财务细节，它们直接影响定价策略。
提交之后审核会看哪些东西？
看功能真实性、权限合理性、隐私合规与安装体验。
功能真实性：描述与实际行为是否一致，截图与演示是不是这个产品。权限合理性：前面说的最小权限原则。隐私合规：有没有可访问的隐私政策页面，说明收集哪些数据、存在哪里、保留多久。安装体验：安装流程是否顺畅，有没有要求用户提供 GitHub 密码这类不应该做的事。
安装体验这一项经常被忽略。正确的授权方式是走平台的 OAuth 或安装流程，让用户在你的应用页面上点击授权，由平台把凭据交给应用。任何要求用户手动粘贴个人访问令牌（PAT）的设计，都是审核的风险点，也是安全风险——令牌的权限往往远大于应用实际需要的。
和飞书应用市场服务商入驻对照，两边都在做同一件事：用权限清单约束应用能碰到的数据边界，用审核流程保证展示信息与真实功能对齐。 规则越细，上架越慢，但对用户是保护。
上架之后的运营重点是什么？
是安装后的留存，不是上架本身。
上架只是拿到一个展示位。用户在 Marketplace 里搜索、比较、安装，决定后续的是两件事：安装后多快能感受到价值，以及出问题时能不能找到人。
第一次安装的体验要压到最短。 理想路径是：从 Marketplace 点安装、选仓库、授权、回到仓库就看到结果。任何需要填写配置文件、跑命令行、等待审批的环节，都会掉一批人。
维护层面要盯三个指标：安装量、卸载量、以及与订阅相关的转化与流失。卸载量比安装量更能说明问题，它反映的是承诺与实际的落差。
什么样的团队适合先上架这里？
做开发者工具、且产品能在仓库里立刻见效的团队。
判断标准是产品价值能否在「装完五分钟内」被感知。代码检查、依赖扫描、发布自动化、issue 与项目管理增强，都符合这个特征；需要长期配置、需要导入大量历史数据的工具，在 Marketplace 里转化会差很多。
渠道选择上也有取舍。面向国内用户的工具，主战场通常在自有落地页与国内的云市场；面向出海开发者，Marketplace 的权重就很高。两者可以并行，但同一套产品的权限申报与隐私政策要按更严的那个标准准备，因为审核材料是复用的。