4、Google Play Console中的版本管理：如何创建应用版本、管理版本号、设置发布轨道
4.1 版本号体系：versionCode 与 versionName
版本号管理是发布流程的第一步，也是坑最多的地方。说白了，Google Play 通过两个字段来识别你的版本：versionCode 和 versionName。
- versionCode：整数类型，必须严格递增。每次上传新版都要比上一版大，否则会被拒绝。
- versionName：字符串类型，展示给用户看的版本名，比如 "3.2.1"。你可以随意改，但建议遵循语义化版本。
我的做法：versionCode 用时间戳或者 CI 构建号来自动生成，避免人为出错。versionName 用 主版本.次版本.补丁号 格式，跟 Git 标签保持一致。
我在项目中遇到过好几次因为 versionCode 重复导致上传被拒的情况。有一次团队里两个人同时打版，一个用了 42，另一个也用了 42，结果后上传的那个直接报错。嗯，从那以后我就改用 CI 自动递增了。
小技巧：在 app/build.gradle 里这样配置，versionCode 自动走 CI 构建号，versionName 从 Git Tag 读取。
android {
defaultConfig {
versionCode = System.getenv("CI_BUILD_NUMBER")?.toInteger() ?: 1
versionName = "3.2.1"
}
}4.2 创建应用版本：一步步来
在 Google Play Console 里创建一个新版本，其实流程很固定。我每次发布都会走一遍这个 checklist：
- 上传 App Bundle：在 "版本" → "版本管理" 页面，点击 "创建新版本"，拖入 .aab 文件。
- 填写版本信息：版本名称（对内）、发布说明（对用户）。发布说明建议写清楚改了啥、修了啥。
- 选择设备排除：某些设备兼容性有问题，可以在这一步排除。
- 检查版本号：确认 versionCode 比上一版大，versionName 符合规范。
- 选择发布轨道：内部测试 / 封闭测试 / 公开测试 / 正式版，根据阶段选。
⚠️ 避坑指南：我曾经在创建版本时忘了勾选 "保留旧版本 APK 供回滚使用"，结果新版出问题时没法快速回退，只能重新走审核流程。花了整整一天才恢复。所以每次创建版本，我都会确认回滚选项是否开启。
4.3 发布轨道详解：四个档位，各有用途
Google Play 提供了四个发布轨道，说白了就是四个不同可见度的发布通道。你想想看，从内部开发到全量发布，每个阶段都有对应的轨道：
| 轨道 | 可见范围 | 典型场景 | 审核要求 |
|---|---|---|---|
| 内部测试 | 仅限添加的邮箱 | 开发自测、QA 验证 | 无需审核 |
| 封闭测试 | 受邀用户 / 链接 | 小范围外部验证 | 部分需要审核 |
| 公开测试 | 所有用户可见 | 大规模公测 | 需要审核 |
| 正式版 | 全量用户 | 正式发布 | 严格审核 |
我个人习惯在 封闭测试轨道 上先跑灰度发布，等数据稳定了再推到正式版。之前做个社交 App 的新功能，就是在封闭测试里发给了 500 个种子用户，发现了一个只在 Android 12 上出现的崩溃，避免了正式版事故。
4.4 灰度发布策略配置：从 1% 到 100%
灰度发布的核心就是 "逐步放量"。在 Google Play Console 里，你可以针对每个轨道设置发布比例。我一般这么配：
- 1% 用户：观察 Crash 率和基本功能，跑 2-4 小时。
- 5% 用户：覆盖更多设备组合，跑半天到一天。
- 20% 用户：接近真实环境，重点看性能指标和用户反馈。
- 100% 用户：确认无误后全量。
我常用的筛选组合：除了按比例，还可以按国家/地区 + 设备特征一起筛。比如 "先发日本 5% 的 Pixel 用户"，这样既能控制风险，又能拿到高质量反馈。
你想想看，如果不做灰度直接全量，万一有个只在特定机型上出现的 bug，后果就是一夜之间差评满天飞。我见过不止一个团队因为这个翻车。
4.5 版本回滚与紧急修复
即便做了灰度，线上还是可能出问题。这时候你需要快速回滚或者发紧急修复版。
回滚的操作路径：
- 进入 Google Play Console → 对应轨道 → 查看版本历史。
- 找到上一个稳定的版本，点击 "重新发布"。
- 确认版本号无误后提交，等待审核通过即可。
⚠️ 紧急修复注意：我曾经在回滚时遇到一个坑——旧版本的 versionCode 小于当前版本，但 Google Play 要求 versionCode 必须递增，所以不能直接"回退"到旧版本，而是要用旧代码 + 新 versionCode 重新打包。换句话说，回滚不是"倒带"，而是"基于旧代码打一个新版"。这个认知很多人搞错。
我的建议：每次发布正式版后，立刻把当前代码分支打上 Tag，并保留一份可直接打包的配置。这样紧急修复时，直接 checkout 那个 Tag，改一行 versionCode，打包上传，最快 20 分钟就能解决。
好了，版本管理这块内容比较多，但说白了就是三个核心：版本号别重复、轨道选对、灰度慢慢放。把这三点抓好，线上事故就能少一大半。