谷歌204个接口藏了3年，这个程序员用1行命令全扒了

去年有个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，第三方先做出来了。