去年有个Android开发者在传AAB包时突然停手——2026年了，为什么还在点鼠标？
他算了笔账：每次发版要开Play Console、传包、填更新日志、选渠道、设灰度比例、点确认。15分钟点击，换一行命令就能搞定的事。更荒诞的是，市面上没有工具能覆盖完整API。Fastlane要装Ruby和150个gem，只支持20个接口；gradle-play-publisher绑死Gradle；bash脚本人走茶凉。
于是他花几个月造了GPC。不是又一个上传工具，是把Google Play Developer API v3的204个端点全映射成命令行。
204个接口，为什么之前没人做全？
Google的API文档躺在那儿，但工具生态是碎的。Fastlane的supply模块2015年写的，只覆盖发布和元数据。订阅管理、评论回复、崩溃分析、购买验证——这些接口存在，但没人在CLI里接。
开发者的真实工作流是：发版用Fastlane，看崩溃开Play Console，查评论再开另一个标签页，订阅问题找财务后台。
GPC的逻辑是统一入口。上传发布：
gpc releases upload app.aab --track beta
查崩溃率：
gpc vitals crashes --version 142
读一星二星评论：
gpc reviews list --stars 1-2 --since 7d
管理订阅：
gpc subscriptions list
冷启动500毫秒内，支持npm、Homebrew、独立二进制。作者原话：「我不想说服团队装Ruby环境。」
真正好用的功能，Google没放在显眼位置
开发过程中作者发现，Play Console里大量能力其实有API，只是没人封装。比如同步70多种语言的商店文案，把崩溃数据拉进监控流水线，或者按健康指标自动卡灰度——如果崩溃率飙升，GPC拒绝扩大发布并告诉你原因。
但他最常用的其实是两个命令。
第一个是preflight，在Google拒绝你之前先自查。
gpc preflight app.aab
9个并行扫描器离线跑，不调用API。检查targetSdk合规、exported标志缺失、受限权限、硬编码密钥、非Play支付SDK、隐私追踪问题、COPPA标识、下载包体积、商店元数据。输出带严重级别的报告，CI里退出码6代表必须修复。
作者说：「我受够了传完包等两小时才收到拒信。」现在这是他流水线的第一步。
第二个是status，一行命令看全 app 健康度。
gpc status
10个并行API调用，返回各渠道活跃版本、崩溃率、ANR率、慢启动率、慢渲染率、近期评论，带趋势箭头和阈值标记。加--watch 30每30秒轮询，加--notify阈值突破时桌面弹窗，--since-last显示上次检查后的变化。
这替代了「开三个Console标签页来回刷」的习惯。
工具背后的判断：CLI是API的终极界面
作者的产品直觉很直白：开发者工具要么进IDE，要么进终端。Play Console的网页界面适合偶尔查看，但发版是高频、可脚本化、需要自动化的动作。网页的每一次点击都是对人力的浪费，而Google官方从未提供完整的命令行方案。
GPC的架构选择也有意思。Node.js生态够轻，但提供独立二进制给不想装运行时的人。204个接口不是简单封装，而是统一了命名风格和参数设计——gpc [资源] [动作] [标志]的模式，比直接curl Google的REST端点少记80%的细节。
有个细节：作者特意处理了API的分页和限流。比如拉取历史评论时，GPC自动翻页合并，返回完整数据集而不是让使用者自己拼offset。
目前项目在GitHub开源，周下载量作者没公开，但npm统计能查到趋势。他提到有团队把GPC编进了GitHub Actions，实现「合并到main分支后自动跑preflight、上传内测、发Slack通知」的完整闭环。
Google会官方跟进吗？历史先例不太乐观。Android Studio的构建工具链迭代缓慢，Play Console的更新多集中在可视化报表。204个接口的完整CLI，第三方先做出来了。
热门跟贴