1. 新增页面并部署至CodePush云端是否可行？ #

当然可行！CodePush的核心就是用来推送React Native的JS代码和静态资源（比如图片、字体）更新，新增页面只要是纯JS层面的实现（没涉及原生代码修改或新增原生依赖），完全可以通过CodePush部署。你写完新页面的组件代码后，执行code-push release-react这类打包推送命令，用户打开APP时就会自动下载并应用这个更新，不用走应用商店的漫长审核流程。

2. React Native CodePush的变更限制有哪些？ #

CodePush有明确的适用边界，主要限制包括：

• 不能新增或修改原生代码（比如Objective-C/Swift、Kotlin/Java编写的模块），也不能新增需要原生集成的第三方依赖（比如需要link的原生库）。这类变更必须走应用商店审核，因为涉及APP原生二进制文件的修改。
• 不能修改原生配置文件，比如iOS的Info.plist、Android的AndroidManifest.xml里的权限声明、启动项、Scheme配置等，这些属于原生层面的变更，CodePush无法覆盖。
• 推送内容必须符合应用商店政策，若通过CodePush推送违反App Store或Google Play规则的内容（比如违规功能、侵权资源），一旦被平台检测到，可能导致APP被下架。
• 版本兼容性限制：CodePush更新必须绑定特定原生版本，比如给原生v1.0.0的APP推送的更新，不能让原生v0.9.0的用户接收，否则可能出现JS代码与原生桥接不兼容的崩溃问题。

3. 同时在CodePush云端和应用商店部署更新，用户是否会在应用商店看到更新按钮？ #

分两种情况来看：

• 如果应用商店的更新是原生版本升级（比如版本号从v1.0.0升到v1.0.1，包含原生代码或配置变更），用户设备会正常检测到应用商店的更新提示并显示更新按钮——这和CodePush更新互不影响，因为应用商店更新是替换整个原生二进制包，优先级更高。
• 如果应用商店的更新只是JS层面内容（这种情况很少见，毕竟应用商店审核慢，没必要这么做），只要应用商店版本号高于用户当前安装的版本，系统依然会显示更新按钮。不过通常最佳实践是：应用商店发布原生层面大更新，CodePush发布JS层面小迭代，避免内容重复。

4. 能否仅向部分用户推送变更？ #

必须可以！CodePush提供了非常灵活的分群推送能力：

• 分阶段灰度推送：比如先推送给10%的用户，验证更新没问题后，再逐步扩大到30%、50%，直到100%全量推送。
• 定向用户组推送：你可以给用户打自定义标签（比如“测试用户”、“付费用户”），然后只推送给带有指定标签的用户群体。
• 按原生版本/设备类型推送：比如只给原生v1.0.0及以上的用户推送，或者只推送给iOS用户，排除Android用户。

这些功能能帮你安全测试更新，降低全量推送的风险。

内容的提问来源于stack exchange，提问作者Rahul Syal