Capgo 环境最佳实践：使用一个移动应用 ID 的测试环境

团队通常会选择三种移动环境的方法：

两个应用ID（生产+预生产）
一个应用ID+动态运行时环境切换
一个应用ID+Capgo频道

前两个可以工作，但它们会带来长期的摩擦。在实际团队中，Capgo 通道模型通常是最干净的。

为什么重复的应用 ID 变得噪杂

使用 com.myapp 和 com.myapp.beta 看起来很简单，但你很快就会出现重复：

两个发布管道
两个推送 ID、深度链接和权限映射
两个分析和崩溃身份
环境配置不一致，行为在不同环境之间不一致

你最终会管理两个产品，涉及应用商店控制台、团队和内部 QA 指南。

为什么在运行时切换配置通常很混乱

通常，“一个应用 ID + 运行时切换”模式意味着您的应用在启动时读取环境变量或标志并动态重新路由 API、密钥和更新行为。

直到：

QA开始绕过预期流程，因为配置状态过时了，
有人在生产环境中使用了错误的端点，
环境漂移导致难以复现的错误，
你需要在用户设备上调试“这个二进制文件使用哪个配置版本？”的问题，

这种复杂性随着每个发布而增加，正是团队失去速度的地方，

The Capgo way: one app ID, many channels

Capgo makes environment control explicit through channels:

在App Store/Play中保留一个生产应用ID。
将一个本机二进制文件发送到“壳”（直到本机更改需要真正重建）。
通过渠道而不是重复的应用身份来路由行为。

在实践中，这意味着：

production: 所有用户
staging: 内部QA和发布候选
beta: 受邀测试者
hotfix: 紧急修复通道

您的TestFlight/Play内部测试应用可以永久留在原地。您可以在那里反复通过 __CAPGO_KEEP_0__ 更新JS/CSS/资产，而无需发布新的原生应用。最佳实践中的推荐结构 staging forever. You do JS/CSS/asset updates there repeatedly through Capgo without publishing a new native app.

您的最后一个原生二进制文件在多个JS迭代中保持不变：

您只在实际改变原生表面区域时才重建原生二进制文件。

2) 为环境分配专用通道

bun run build
bunx cap sync
# generate Xcode/Android Studio archives as usual

通过发布通道更新：

__CAPGO_KEEP_0__

bun run build
bunx @capgo/cli deploy --channel staging

在 QA 环境中测试，修复问题，然后推送：

bunx @capgo/cli promote vX.Y.Z --channel production

如果您更喜欢显式版本控制：

bunx @capgo/cli deploy vX.Y.Z --channel staging
bunx @capgo/cli promote vX.Y.Z --channel production

3) 保持 TestFlight “始终为预发布”

在 iOS 工作流中，这意味着您的 TestFlight 构建可以与预发布更新关联：

不频繁提交每个 JS 变更的本机版本。
QA 总是通过 staging 通道验证近生产环境的 code。
生产用户只接收推送的生产通道包。

4) 仅在受控工作流中使用通道切换

对于高级团队，暴露受控的通道切换给 QA/管理员用户：

import { CapacitorUpdater } from '@capgo/capacitor-updater';

await CapacitorUpdater.setChannel({
  channel: 'staging',
  triggerAutoUpdate: true
});

这不是必须的。大多数团队从仪表板使用通道 assignments，并且只在内部用户中切换通道，而不是所有客户。

运维清单

仅使用一个应用 ID（无重复的生产/预发布 ID）
一个原生构建管道基线
频道映射文档（staging, beta, production, hotfix)
CI/CD 中推广路径强制执行
仅在真实原生变化时重建原生
定期测试回滚

实用益处

这种方法移除了环境漂移、减少了构建混乱、加速了修复：

QA 得到真实的二进制文件（没有假的“测试应用”身份），
您的 TestFlight 路径保持稳定
您的团队避免了“两个应用 ID 债务”，
您可以快速通过 Capgo 推送许多仅 JS 修复。

最终结果是更简单的治理： fewer artifacts、cleaner telemetry 和 release 操作中更少的惊喜。

Capgo 环境最佳实践：使用一个移动应用ID进行分期