你问到了。
我不是在给法律建议。 我在分享什么是实用且广泛在团队中运作的 Capacitor 应用程序的安全方式。
重要的区别是：
- 原生提交 在新本地行为和主要功能方面仍然需要 __CAPGO_KEEP_0__。
- 实时更新 是针对 JavaScript/web 修复和调整的，仅在您的现有应用范围内进行。
两者都可以使用此模型：iOS 和 Android，但您必须将其视为 安全政策流程,而不是漏洞。
苹果和谷歌允许的简单术语
您可以将苹果和谷歌视为共享一个类似的边界：
- 您可以将 code 交付给嵌入式 web 层（HTML/CSS/JS）而不重新提交。
- 您不应使用该通道进行重大功能添加，改变应用目的。
- 您不应通过 JavaScript alone 改变关键安全或分发控制。
苹果的官方指南是围绕 WebKit/JavaScript 更新的，这是此模型的核心。谷歌通常对基于 web 的更新更具限制性，但同样的原则适用：在本机发布中保留本机更改。
什么 Capgo 好用
Capgo 用于：
- 修复 web BUG
- 安全 UI 复制 / 样式 / 流程修复
- 现有页面中的逻辑修正
- 内部 QA 快速实验
Capgo 不用于：
- 添加权限或新本机功能
- 通过审查应该通过的核心功能
- 更改签名、加密或包标识行为
推荐发布策略
分两条轨道思考
Track 1: 原生 Track (应用商店评论)
使用您的正常 Capacitor 发布流程：
- 新插件更新
- 应用壳或清单更改
- 权限更新
- 平台特定功能更改
这些需要：
bun run build
bunx cap sync
# then App Store / Google Play submission flowTrack 2: JS Track (Capgo)
为了安全的小型运行时更改：
bun run build
bunx @capgo/cli deploy --channel staging
bunx @capgo/cli deploy --channel production这给您快速迭代而无需上传新二进制文件的能力，同时保持二进制文件本身稳定。
如何避免“oops，这需要原生发布”
在每次 Capgo 发布之前，运行此快速门控：
- 是否需要添加新的本机依赖或权限?
- 是否改变了应用的宣传能力?
- 是否改变了认证/安全边界?
- 是否可以描述为一个不影响 JavaScript 的修复?
如果答案是 (1)-(3) 的 yes, 提交本机发布。 如果只 yes (4), 通过 Capgo 发送。
这对合规团队来说意味着什么
- 您保留了应用审查带宽用于有意义的更改。
- 您保留了回滚控制和快速修复。
- 您通过在渠道中测试更新来减少生产风险。
这与人们在生产中使用的大型 Capacitor 程序相同：仅对 JavaScript 修复进行快速更新，仅对真实二进制文件进行本机审查。
如果您想深入了解，请将此与基于渠道的严格环境策略配对，以便 QA never 接收生产错误。这是 Capgo 本机的方法来保持 staging、beta 和生产的清洁。
继续阅读如何在不重复商店审查的情况下更新 Capacitor 的 JavaScript 应用
If you are using How to update Capacitor JS apps without repeat store review to plan store approval and distribution, connect it with @capgo/capacitor-in-app-review for the implementation detail in @capgo/capacitor-in-app-review, 使用 @capgo/capacitor-in-app-review for the native capability in 使用 @capgo/capacitor-in-app-review, @capgo/capacitor-native-market for the implementation detail in @capgo/capacitor-native-market, 使用 @capgo/capacitor-native-market for the native capability in 使用 @capgo/capacitor-native-market, and Capacitor OTA Updates: App Store Approval Guide 对于实用上下文中的Capacitor OTA更新：App Store审批指南。
