常见问题

复制包含安装步骤和该插件完整 Markdown 指南的配置 prompt。

如果这里没有解决您的问题，请随时提问！无论是提交 Issue 还是在 Discord 上提问，我们都会响应。

什么是“code push”？

Code push，也被称为“空中下载更新”(OTA)，是一种云服务，允许 Capacitor 开发者向生产环境中的 App 推送更新。Capgo 目前支持 Android、iOS 和 Electron。

“Code Push”是指 React Native 社区中由 Microsoft 以及 Expo，两者都不支持 Capacitor。

Capgo CLI 的 major 版本需要和我的插件或 Capacitor 版本匹配吗？

不需要。请始终使用最新的 Capgo CLI (npx @capgo/cli@latest)。CLI 和 Capgo Console 遵循各自的版本控制，并与任何受支持的 updater plugin 大版本保持兼容。Capgo 插件遵循 Capacitor 大版本；请参阅 Capgo 版本控制以获取 LTS 标签，例如 @lts-v7.

bundle 和 release 有什么区别？

我们使用“release”一词是指为 App Store 或 Play Store 准备二进制文件。为了随后生成 bundle，Capgo 需要知道分发到应用商店的具体二进制文件。

我们使用“bundle”一词是指可以应用于 release 以将其更新到新 code 的补丁。 npx @capgo/cli@latest bundle upload 该命令用于从你本地新的 code 生成 bundle，然后分发给你的用户。

Delta 更新有文件路径限制吗？

是：

零字节文件： CLI 会记录 Ignoring empty file... 并从 delta 文件中排除空文件。这不会让 upload 失败，因此空文件可能会改变最终生成的 bundle，而不会中断你的部署。请勿在 Delta bundle 路径中包含零字节文件。
带空格的路径： 当 bundle 路径包含空格时，Delta upload 会提前失败并给出明确错误。在上传 Delta update 之前，请重命名文件或目录以移除空格。

查看增量更新查看设置详情。

路线图是什么？

我们的项目看板也是公开的，地址如下： https://github.com/orgs/Cap-go/projects

我们的团队也在公开环境下工作，因此你可以随时看到我们在做什么。如果你对我们的路线图或优先级有任何疑问，欢迎通过 Github issues 或 Discord.

我可以在团队中使用 Capgo 吗？

可以！所有套餐都支持不限数量的开发者。我们只按组织限制应用指标（MAU、存储和带宽）。

查看团队了解更多信息。

Capgo 会存储我的 code 吗？

不会。Capgo 服务器永远不会看到您的源码 code。当您运行 npx @capgo/cli@latest bundle upload时，Capgo 存储的是压缩后的混淆/编译版 code zip 文件 —— 这与浏览器接收到的 code 相同，而非您的源码 code。

为了进一步提升安全性，您有两种选择：

端到端加密：在上传前对 bundle 进行加密，以保护其在存储和传输过程中的安全，并防止第三方在没有您私钥的情况下生成有效的加密更新。这并不能让已发布的 Web 资源无法被逆向工程，因为公钥已包含在分发的 App 中。
外部 URL 上传：将 bundle 存储在您自己的服务器上，并仅向 Capgo 提供下载链接，并包含该选项 --external <url>

另请参阅我们的隐私政策： https://capgo.app/privacy

bundle 文件是私有数据吗？

不属于。Bundle 文件是公开的 Web 资源，旨在供您的应用用户下载。任何知道 bundle URL 的人都可以获取这些文件，Capgo 已在设置过程和文档中告知用户这一点。

访问 bundle 文件不被视为数据泄露。请勿在应用 bundle 中存放密钥、凭据、个人数据或受监管的数据。如果高安全性场景需要更强的机密性，请使用端到端加密，但在安全报告层面，仍需将分发的应用 code 和资源视为公开内容。

我可以在 CI 系统中使用 Capgo 吗？

可以。Capgo 本就是为了在 CI 系统中使用而设计的。我们已经发布了一份指南，用于 Android 与 Github 操作以及 iOS，以及针对 GitLab。其他 CI 系统也应类似。

如果您遇到任何问题，请随时通过 GitHub 问题反馈或 Discord 联系我们。

这和 Firebase Remote Config 或 Launch Darkly 有什么关系？

Code push 支持在设备上添加新的 code 或替换 code。Firebase Remote Config 和 Launch Darkly 都是配置系统，允许您在无需发布新版本的情况下更改应用配置。它们并非旨在取代 code。

这会增加多少依赖体积？

我最近没有测量过，但我预计 code 推送库会让 Capacitor 应用的体积增加不到 1 MB。当减小体积成为优先事项时，我们有一些办法可以做到。如果体积对你来说是个障碍，请告诉我们！

Capgo 支持 iOS 18.4 Simulator 吗？

不支持。由于影响 iOS 18.4 模拟器的上游问题，Capgo 在该环境下无法稳定运行。请使用真机测试，或换用其他版本的 iOS 模拟器。

详情请见 React Native 的 issue： facebook/react-native#50510

code 的 push 功能适用于大型应用吗？

是的。通过 code 推送更新应用时，没有体积限制。正如之前提到的下方，Capgo 可以更改应用中任何大小的 JS code。

需要注意的是：体积越大，用户下载更新的难度就越高。我们建议尽可能保持应用体积精简。

Capgo code push 可以用来做什么？

我们见过多种应用场景，包括：

对生产环境应用进行紧急修复。
为使用旧版本应用的用户推送 Bug 修复。
进行高频推送（例如每小时一次）。

请注意，大多数应用商店禁止通过 code 显著改变应用的行为。请参阅下方了解更多信息。

Capgo 的 “MAU” 是如何计算的？

MAU 指每月活跃设备（Monthly Active Device）。在滚动 30 天周期内与 Capgo 通信的独立设备，会计为该 native app ID 的一个 MAU。同一台物理设备使用两个不同的 native app ID 时，会分别为每个 app ID 各计一次，不会跨 app ID 去重。

如果您的 flavors 仅在 Web 层或更新路由上不同，请使用同一个 native app ID，并搭配频道。这样可以让这些 flavors 都归在同一个 Capgo app 下，发布也更简单。当某个 flavor 需要独立的 bundle ID、签名身份、entitlement 集合或商店详情页时，请使用不同的 native app ID。

在 iOS 上， v7.25.0+ 会借助 Keychain 在常规重装后保留随机、按 app 作用域划分的设备 ID。在 Android 上，请使用 v7.50.1+ (或 v5.50.1+ 以及 v6.50.1+ 在这些发布版本上）；仅当 Android Backup/Restore 保留应用偏好设置时，ID 才会恢复。禁用备份、排除这些偏好设置或清除应用数据都会生成新的设备 ID。更新应用不会创建新的设备 ID。

对于测试和开发构建，请在生产渠道中关闭 development-build 和模拟器投递。这控制的是投递，而不是 MAU：设备在联系 Capgo 时仍可能被计入。要让它不计入生产用量，请禁用 Live Updates，并且不要调用生产环境的 Capgo 端点。请参阅无需 Live Updates 测试 Native Build 查看具体设置。

哪些场景不能使用 Capgo code push？

Capgo 无法更改 Java、Kotlin、Objective-C、Swift、native plugins 或 native configuration 等原生 code。这些更改需要发布新的原生应用版本。有关应用商店审核范围，请参阅 App Store 和 Google Play 政策.

我可以通过 Capgo 更新 capacitor.config.ts 的改动吗？

不可以。简而言之：Capgo 可以发送生成的 web build 文件夹，包括 HTML、CSS、JavaScript、assets 以及打包在该输出中的纯 JavaScript package 更改。但以下更改 capacitor.config.ts，native plugin 配置、native package 的安装或升级，以及任何必须通过 iOS 或 Android 项目进行更新的内容 npx cap sync 或 npx cap copy 都需要发布原生应用版本。

Capacitor 配置文件在 native build 时读取并编译进原生应用二进制文件中。如果你需要更改 Capacitor 配置，你必须：

更新 capacitor.config.ts 在本地
重新构建您的 Native Build (npx cap sync 随后进行 Native Build)
将新的二进制文件提交至应用商店

Capgo 会帮我提交到应用商店吗？

Capgo Build 可以编译并签名已准备好的 iOS 或 Android 原生项目，并在配置完成后，将签名后的结果提交至 App Store Connect 或 Google Play。您可以保留现有的 CI 用于处理私有依赖、Web 构建、Capacitor 同步以及自定义原生准备工作；Capgo 会接收准备好的原生项目以进行 Native Build 步骤。

查看 Capgo 构建以及构建配置参考了解工作流和应用商店提交选项。

Capgo 会在磁盘上存储什么，存在哪里？

Capgo 更新程序（在构建应用时已包含在您的应用中）会将最新下载的 bundle 缓存到 capacitor 允许加载 code 的唯一目录中。在 Android 上，该目录位于 /data/user/0/com.example.app/code_cache/capgo_updater 尽管该路径的基础路径由 Android 系统提供，并可能在运行时动态变化。在 iOS 设备上，数据存储在 Library/Application Support/capgo.

Capgo 命令行工具（例如 npx @capgo/cli@latest bundle upload）安装在磁盘上的 npm 缓存中，您的登录信息存储在主目录的 ~/.capgo.

这与 Capacitor Hot Reload 有什么关系？

Capacitor 的 Hot reload 仅限开发阶段使用。Code push 则用于生产环境。

Hot reload 是 Capacitor 的一项功能，允许您在开发期间更改设备上的 code。它需要构建带有代理的 Capacitor 应用，以便连接到您的本地机器。

Code 推送功能允许您在生产环境中的设备上更改 code。我们会根据平台采用多种技术来实现。

Capgo code push 支持哪些类型的更改？

Capgo 可以更改应用中的任何 JS code。这包括应用 code 和生成的 code。您还可以更新以下位置的依赖： package.json 只要这些更新不需要原生 code 更改。

我们目前没有计划支持更改原生 code（例如 Android 上的 Java/Kotlin 或 iOS 上的 Objective-C/Swift）；如果工具检测到您更改了原生 code，它会发出警告，因为这些更改不会包含在 bundle 中。

这支持 Web 端吗？

Web 端不需要 Code 推送，因为 Web 本来就是这么工作的。用户打开 Web 应用时，它会按需从服务器下载最新版本。

如果您有在 Web 端使用 code 推送的场景，欢迎告诉我们！

它能在 iOS、Android、Mac、Windows、Linux 等平台上运行吗？

是的。

到目前为止，我们主要支持 Android、iOS 和 Electron，code 推送在这三个平台上均已可用于生产环境。

Capgo 支持哪些操作系统版本？

Capgo 支持的 Android 版本与 Capacitor 相同。

Capacitor 目前支持 Android API level 22+ 和 iOS 13.0+： https://capacitorjs.com/docs/main/reference/support-policy

Capgo 支持哪些版本的 Capacitor？

Capgo 目前仅支持 Capacitor 的近期稳定版本。我们也可以支持更旧版本的 Capacitor，只是还没有构建出长期维护这些版本所需的基础设施。我们计划未来支持更多 Capacitor 版本，包括为企业客户支持任意版本。 https://github.com/Cap-go/capgo/issues/1100

Capgo 会跟踪 Capacitor 的稳定版，通常在任何稳定版本发布后几小时内完成更新。我们的更新系统是自动化的，运行一次只需几分钟。之后我们还会额外做一次手动验证，再发布到服务器。

这与 App Store/Play Store 的审核流程或政策有什么关系？

Capgo 只向 Capacitor 的 Web 层交付变更：即已在应用 WebView 中运行的 HTML、CSS、JavaScript 和资源文件。它不会更改原生二进制、原生插件、权限、entitlements、签名或商店元数据。

任何原生变更，以及可能影响应用审核用途或功能的重大变更，都应通过原生商店版本发布。请确保 Live Updates 的内容不超出您已提交并向用户披露的应用体验范围。

Capgo 会导致 Apple 以远程 code 执行为由拒绝吗？

不会。这不可能发生。Capgo 不会安装或执行原生 code、动态库、框架或插件，也无法调用 dlopen, dlsym, performSelector:，或 method_exchangeImplementations()。它只替换已编译进受审核二进制文件中的 WebView 或 JavaScriptCore 引擎里的 JavaScript、HTML、CSS 和静态资源。

当 App Review 引用 Guideline 2.5.2 或“远程 code 执行”时，不要将 Capgo 视为原因。请阅读审核通知，然后检查原生项目和其他 SDK 是否存在可执行文件加载或私有 API 的使用。此前有一条审核意见提到 Capgo 启动页自动隐藏路径中的动态链接问题，那是该原生插件的 bug，而不是 live updates，且该链接已被移除。

Apple 对远程 code 执行的限制会影响 Capgo 吗？

不会。Capgo 不会导致远程 code 执行被拒。请参阅 Capgo 会导致 Apple 以远程 code 执行为由拒绝吗？。Capgo 是为 Capacitor 应用中的解释型 Web 层构建的。它不会在审核后安装或执行原生 code。Apple 仍会依据每个 App 的实际情况单独审核，Capgo 无法保证结果。

Apple 的 App 审核指南 2.5.2 规定应用不得“下载、安装或执行会引入或改变应用特性或功能的 code”。审核团队会援引该规则以及 Apple Developer Program License Agreement 第 3.3.1(B) 节 中关于可执行 code 的规定，审核团队会据此拒绝在审核通过后使用远程资源改变行为的应用。典型案例包括 dlopen, dlsym, performSelector:，或访问私有 API 的远程脚本。

同一份许可协议允许 解释型 code 在满足以下条件时下载：

不会改变 App 的核心用途，
不会绕过签名、沙盒或其他 OS 安全特性，且
不会为其他应用创建商店或店面。

章节 3.3.1(C) 另行限制通过 App Store、Custom App Distribution 或 TestFlight 以外的分发机制提供、解锁或启用额外功能或特性，除非 Apple 事先书面批准，或该活动属于该条款允许的范围 3.3.9(A) （App 内购买 API）。该条款如何适用于某个解释型 code OTA bundle，是你的团队和法律顾问需要判断的法律问题。

Capgo 替换的是已经在你 App 的 WebView 或 JavaScriptCore 引擎中运行的 JavaScript、HTML、CSS 和静态资源。它不会随包发布原生二进制文件、机器 code、动态库或插件。指南 4.7 （澄清于 2025 年 11 月) 适用于你的 App 提供 HTML5 和 JavaScript 小程序、小游戏、聊天机器人、插件或类似未嵌入二进制文件的软件。如果用户能在你的 App 内浏览或启动多个不同的软件体验，请与法律顾问一起评估额外的 4.7 要求。单一产品通过渠道更新自己已审核的 web bundle，是另一种用户体验，但只有 Apple 能决定你的元数据是否符合该描述。

通过常规 App Store 二进制包发布原生能力、权限、entitlements 和重大功能变更。对于已提交 App 范围内的 Web 层修复和改进，请使用 Capgo。参见 Apple 远程 code 执行与 Capgo 如需更详细的合规性分析，或查看博客指南关于 Guideline 2.5.2、ADPLA 3.3.1(B) 以及 2025 Guideline 4.7 的说明。

Capgo 能保证通过 App Store 或 Google Play 审核吗？

不能。Apple 和 Google 会根据每款 App 的具体情况进行独立审核与发布，Capgo 无法保证单个 App 的审核结果或通过率。您的团队仍需负责 App 的内容、信息披露、更新范围以及对当前应用商店政策的合规性。

有关审核与发布规划，请直接阅读官方政策： Apple App Store 审核指南以及 Google Play 设备和网络滥用政策.

我可以在我所在的国家使用 Capgo 吗？

我们并未尝试限制任何国家访问 Capgo。

我们了解到，某些国家对境内可访问的 URL 有限制。Capgo 目前使用 Cloudflare Cloud 托管，包括 R2 Storage 和 Cloudflare workers。

Capgo 使用以下 URL：

https://api.capgo.app — 用于 npx @capgo/cli 命令行工具与 Capgo 服务器交互，以及用户设备上的 Capgo updater 检查更新。
https://*.r2.cloudflarestorage.com — 用于 npx @capgo/cli 用于上传和下载 bundle 的命令行工具

如果这些 URL 在你所在的国家都能访问，那么 Capgo 应该就能正常工作。

如果您的地区需要屏蔽其中任何 URL 的访问，请告知我们，我们可以与您共同寻求解决方案。使用代理服务器是一个可行的选项。

我可以自托管 Capgo 吗？

可以。当您需要在自己的基础设施中运行 updater 后端时，Enterprise 版本支持授权的自托管 Capgo 部署。请参阅自托管 Updater 以了解部署模式和端点。

code 推送需要联网才能工作吗？

是的。虽然可以考虑通过独立于公共互联网的服务器来分发更新，但仍需要某种形式的网络连接才能将更新传输到设备。

没有网络连接时，Capgo 会受到什么影响？

Capgo 更新器（使用 Capgo 构建应用时会包含在你的应用中）在设计上能够应对网络连接问题。

在默认更新行为下，应用启动时会通知 Capgo 更新器，后者会启动一个独立线程，向 Capgo 的服务器发起网络请求并请求更新。我们特意使用独立线程，是为了避免阻塞应用可能正在执行的其他任务。如果网络请求失败或超时，更新器会在下次应用启动时再尝试检查。

Capgo 命令行工具（例如 npx @capgo/cli@latest bundle upload）需要网络连接才能运行。如果你使用 Capgo 分发应用，请确保你的 CI 系统可以联网。

如果用户长时间未更新并错过了某次更新，会发生什么？

我们的实现始终会向发起请求的设备发送专门适配的更新，把请求方更新到当前可用的最新版本。因此，如果用户一段时间不更新，就会“错过”中间的更新。

更新服务器可以调整，以根据你的应用需求返回下一个增量版本或最新版本。如果其他更新行为对你很重要，请告诉我们。

Capgo 与 Capacitor 是什么关系？

Capgo 是 Capacitor 的一个插件，它增加了 code 推送功能。Capgo 并不是 Capacitor 的替代品。你可以继续使用你熟悉且喜爱的 Capacitor 工具。

我们会跟踪 Capacitor 的最新稳定版本，并更新我们的 code 推送插件以保持兼容。

更新会在什么时候发生？

默认情况下，Capgo 更新程序会在应用启动时检查更新。它在后台线程运行，不会阻塞 UI 线程。任何更新都会在用户使用应用时进行安装，并在下次重启应用时生效。

你也可以通过以下方式手动运行 Capgo 更新程序： @capgo/capacitor-updater 使用该 package，你可以随时触发更新，包括通过推送通知触发。

Capgo 更新器旨在确保在网络不可用、服务器宕机或无法连接时，应用仍能正常运行。即使您选择从我们的服务器中删除某个更新，您的所有客户端也将继续正常运行。

我们新增了回滚补丁的功能。最简单的方法是直接将之前的 bundle 重新关联到您的 channel 即可完成回滚。

我需要对 app_id 保密吗？

不，不是的。 app_id 已包含在您的应用中，公开也是安全的。您可以将其提交到版本控制系统（甚至是公开仓库）中，无需担心被他人获取。

即使有人获取了您的 app_id 也可以从 Capgo 服务器获取您应用的最新版本，但他们无法向您的应用推送更新，也无法访问您 Capgo 账户的任何其他方面。

哪些信息会发送到 Capgo 服务器？

完整的数据清单、端点行为和隐私控制详见合规性.

设置 statsUrl: '' 以禁用显式更新器统计报告。你也可以将数据发送至 statsUrl 你控制的代理或端点；请参阅在自托管基础设施中处理统计数据。更新检查仍需应用范围内的设备标识符，以便 Capgo 选择正确的更新并统计月活跃设备数。

本指南中介绍的子处理者列表是我们关于供应商、处理地点、传输机制及变更历史的最新公开权威来源。

我可以在涉及 HIPAA 敏感数据的应用中使用 Capgo 吗？

可以，但您的合规负责人需要选择合适的部署模式。Capgo Cloud 目前尚未作为符合 HIPAA 标准的托管统计数据处理器提供。默认情况下，更新程序数据是基于设备范围的，并不与特定的应用用户绑定，许多团队已成功采用该模式。

如需通过更严格的审核，您可以对插件流量进行地理位置限制，通过将 statsUrl 设置为空字符串来禁用统计功能，仅自托管统计端点，或使用授权的自托管方案。请勿在调用 CapacitorUpdater.setCustomId(...) 时包含电子邮件、用户 ID、患者 ID、员工 ID 或任何能将更新程序遥测数据关联到个人的值。

查看 HIPAA 合规以了解完整的技术配置，以及禁用统计功能时在可观测性方面所做的权衡。

我可以把 Capgo live update 数据保存在欧洲吗？

可以。对于 Capgo Cloud 插件流量需要满足欧盟数据驻留要求的应用，可以将更新程序端点设置为欧盟主机：

updateUrl: https://plugin.eu.capgo.app/updates
statsUrl: https://plugin.eu.capgo.app/stats
channelUrl: https://plugin.eu.capgo.app/channel_self

请同时使用这三个 EU URL，以确保更新检查、统计数据和 Channel 自分配使用相同的区域数据路径。由于这些值存储在 capacitor.config.ts，生产环境的移动应用需要先发布一个 Native Build，现有安装版本才能使用新的端点。

查看数据位置查看 Capacitor 和 Electron 的确切示例。

Capgo 支持哪些平台？

目前，Capgo 支持 Android、iOS 和 Electron。所有平台均已达到生产级标准。

您可以独立决定是否在 iOS、Android 或 Electron 上使用 Capgo。您可以根据需要，分别为 Android、发布到 App Store 的 ipa 或 Electron 设置 Channel 策略。

Capgo 可以（相对容易地）扩展以支持桌面端或嵌入式目标平台。如果这些对您很重要，请告知我们。

Capgo 如何与 Play Testing Tracks 或 Apple TestFlight 配合使用？

各大应用商店都有各自的机制，用于向特定用户群体分发应用（例如“内部测试”、“封闭测试”等）。这些机制的核心都是将用户进行分组，并将特定版本的应用分发给每个组。

遗憾的是，并非所有这些机制都允许第三方检测应用是否安装在特定的测试轨道或通过 TestFlight 安装。因此，我们无法可靠地获知这些分组的具体构成，也无法基于这些分组来可靠地控制 Capgo patch 的访问权限。 https://stackoverflow.com/questions/53291007/can-an-android-application-identify-the-test-track-within-google-play https://stackoverflow.com/questions/26081543/how-to-tell-at-runtime-whether-an-ios-app-is-running-through-a-testflight-beta-i

如果您想对 Capgo bundle 的可用性进行分组管理，有以下 4 种潜在方案：

为每个分组使用独立的 channel。这是最直接的方法，但需要您管理多个 channel。您可能已经拥有了可用性不同的 dev channel 和 prod channel。因此，您可以先更新 dev channel 并进行验证，然后再单独更新 prod channel。我们建议在版本控制中使用 branches / tags，以帮助追踪与每个 release 相关的源码。
Track your own set of opt-in users, disable automatic updates, and trigger updates only for certain users via the @capgo/capacitor-updater 该功能目前可用，但需要你自行管理选择加入列表。
Capgo 支持按设备创建自己的选择加入机制（类似 Test Tracks 或 TestFlight，但不限平台）。这样你的 QA 团队就能在 bundle 向公众发布前选择加入。
使用渐进式发布将候选 bundle 推送给某个 channel 中随机且固定的用户子集。设置 0–100% 的发布比例，或使用 --rollout-percentage-bps 以 0.01% 为增量；可配置 60 秒到 365 天的缓存时长，以及可选的自动暂停策略。此功能不会选择指定名称的设备组。

计费

如何升级或降级我的套餐？

你可以随时在 dashboard 中升级或降级方案： https://console.capgo.app/settings/organization/plans。升级会立即生效。降级会在当前计费周期结束时生效。

如果我达到了 MAU 上限会怎样？

Capgo 会在你的 MAU 用量达到上限的 50%、70%、90% 和 100% 时给你发邮件。一旦达到上限，Live Updates 会被阻止，直到当前计费周期结束。升级到更高方案或购买 credits 以恢复更新服务。请参阅 Capgo 价格以及定价了解方案档位。

你们提供退款吗？

除法律要求外，已支付的订阅费用不予退还。部分退款申请可能由 Capgo 自行决定逐案审核。请联系支持团队如果您认为自己符合条件。

我的计费周期何时重置？

账单周期每月自动重置，重置日期为您首次订阅 Capgo 的当天。例如，如果您在 15 日订阅，账单周期将在每月 15 日重置。

如何取消我的订阅？

您可以随时在 dashboard 中取消订阅： https://console.capgo.app/settings/organization/plans

我可以预付一年的费用吗？

可以。您可以在 organization plan settings 中选择按年计费.

哪些内容计入存储空间，我们可以更改保留期吗？

存储空间包括各 channel 中保留的历史 bundles 及其 Delta assets。您可以在 App Settings 中控制每个 App 未使用 bundle 的保留策略。与活跃 channel 或 rollout 关联的 bundles 会受到保护，以确保其可用于发布和回滚。

区域复制会增加存储或带宽消耗吗？

不会。无论由哪些区域提供服务，一个 bundle 在存储计算中仅计为一次。带宽也不会因区域增加而翻倍：请参阅带宽是如何计算的？.

带宽是如何计算的？

带宽仅计算设备实际从 Capgo 下载的文件：

增量更新 (Delta updates)： when you upload with --delta，设备仅下载自当前版本以来发生变化的文件。只有这些文件会计入带宽。未更改的文件（如大型图片或字体）不会被重复下载，因此不产生费用。详见增量更新.
边缘缓存： 如果请求的文件或完整 zip 已在边缘缓存，则该下载不计入带宽。Delta 文件和完整 zip 都适用。
断点续传： 如果下载中断，设备会从中断处继续。已下载的部分不会重复下载，也不会重复计入带宽。
完整 zip： 未上传 bundle --delta或使用不支持 Delta 的插件版本的设备，会下载完整 zip。只有未从边缘缓存提供时才会计入带宽。

为了降低带宽消耗，请使用 --delta 并将很少变动的大型资源放在稳定的文件路径中。

Enterprise SLA 包含哪些内容？

Enterprise 版本承诺生产平台每月 99.9% 的可用性。若未达到该承诺，将根据每月可用性提供 10% 至 30% 的服务抵扣额度。初始支持响应目标为：P1 级：1 小时（24/7/365）；P2 级：2 个工作小时；P3 级：1 个工作日；P4 级：2 个工作日。请阅读企业级 SLA 以了解完整条款。

统计与分析

您 dashboard 中的统计数据每天 UTC 午夜更新。统计数据根据独立 MAUs （滚动 30 天周期内活跃）计算得出。

设备 ID 的生成方式

设备 ID 在首次运行时于设备本地生成，用于对每台设备的安装去重，并让我们可以按安装用户数（例如月活跃用户数）计费，而不是按补丁总数或补丁安装总数计费。

用 MAU 给 Capgo 定价比按安装量更合适，因为它更准确，也能反映每台设备 Capgo 的实际成本。

设备 ID 持久化：

iOS: 从 v7.25.0+ 开始，设备 ID 存储在 Keychain 中，普通重装后仍会保留。
Android: 请使用 v7.50.1+（或对应版本线的 v5.50.1+/v6.50.1+）。仅当 Android Backup/Restore 保留应用偏好设置时，设备 ID 才会恢复。
Electron: 设备 ID 存储在安全存储中。
Android 注意事项: 禁用备份、排除相关偏好设置或清除应用数据都会生成新的设备 ID。在 Android v7.25.0 至 v7.50.0 中，即使启用了备份，重装后仍可能生成新的设备 ID。

设备 ID 仅限于应用作用域，支持 Live Update 推送和 MAU 去重；它不是广告或跨应用追踪标识符。

设备 ID 会在应用通过 updater 或 stats 端点向 Capgo 进行 Check-in 后列出。设备无需安装 patch 即可出现在设备列表中。

为什么我的设备数量与 MAU 不一致？

设备列表与 MAU 是基于不同的信号计算的。

设备列表显示每个设备的最新已知元数据，例如设备 ID、平台、plugin 版本、OS 版本、native 版本、channel、已安装的 bundle 以及请求国家（如果可用）。请求国家是该设备通过 Cloudflare 处理的请求中收到的最新有效的两位代码 code，而非 GPS 或应用提供的定位。不含有效国家信息的请求不会清除上一次的有效值。Capgo 会在应用 Check-in 时更新这些元数据，但如果重复 Check-in 上报相同的元数据，可能不会更改该行或其最后更新时间。

MAU 统计的是计费周期内不同的活跃设备。即使设备元数据保持不变，活跃度也可能增加，因此设备数量和 MAU 可能会有所不同。

如何针对不同平台实现不同的更新？

您可以为每个平台创建独立的 channel，并在每个 channel 中禁用特定平台的更新。

例如，在 iOS channel 中禁用 Android 更新，在 Android channel 中禁用 iOS 更新。

然后，为每个 channel upload 一个 bundle，从而实现不同平台的差异化更新。

如果两个平台需要相同的更新，您可以将同一个 bundle 关联到多个 channel，无需重复上传 bundle。

继续阅读 FAQ

如果你正在使用 常见问题 要规划 live update 的交付，请将其与 Capgo Live Updates 用于 Capgo Live Updates 中的产品工作流，概览用于 Overview 中的实现细节，功能用于 Features 中的实现细节，更新行为有关 Update Behavior 中的实现细节，请参阅更新类型关于 Update Types 中的实现细节。