国内安卓 App 已经上架国内商店，客户想再发一个 Google Play 版本，原来的包直接传上去会卡在哪一步？

国内应用商店已上架的 Android 包，原封不动传到 Google Play，被打回的概率偏高。卡点通常不在业务代码，而在账号登录、支付路径、推送通道、地图定位与数据安全表单这几层服务依赖没换。按 2026 年常见项目交付习惯，Android 出海更像「复用业务层、替换服务层」，而不是把 App 再做一遍，改造量经验区间约为原开发量的 20% 到 40%。

同一个包传上去，审核通常卡在哪几层

Google Play 的审核看两件事：应用实际依赖哪些系统服务，以及开发者在后台申报的内容与包内实际行为是否一致。国内包常见做法是绕开 GMS，推送走厂商通道、定位走国内地图 SDK、登录走微信或 QQ，这些在审核视角里会被逐项比对。经验上，被打回的原因里，政策与申报不一致比程序崩溃更常见。

还有一类容易被忽略：功能在新市场跑不通。如果 App 首次启动就要求手机号加验证码，而短信通道只覆盖国内号段，海外用户会直接卡在登录页。这种装得上但走不下去的包，通常被判定为体验不达标，而不是单纯的合规问题。

• 账号层：微信、QQ 登录在海外可用性有限，需要补目标市场常用的账号或邮箱登录。
• 支付层：数字商品通常要走平台内购，自有支付通道不能替代。
• 推送层：国产厂商推送通道在海外机型上无法送达，需要接统一推送方案。
• 地图定位层：国内地图 SDK 在海外覆盖有限，坐标系与权限申报口径也不同。
• 隐私与申报层：数据安全表单、隐私政策与包内实际采集行为要逐项对齐。

出海改造按四层盘点，顺序为什么不能乱

按四层来盘，是因为每一层的返工代价不同，而且是从下往上牵动的。依赖层没盘清就去改账号层，容易改完才发现推送和统计 SDK 也得动，前面的测试还要重跑一遍。先把四层列成一张表，再决定哪些放本期、哪些放下一期，比先动手改代码再回头补合规省时间。

1. 依赖层：把包内第三方 SDK 逐个列出，标注在目标市场属于可用、不可用还是需替换。
2. 账号层：确认登录方式在当地能不能跑通，短信通道要用目标市场真实号码实测送达。
3. 支付层：先区分实体商品与数字商品，数字商品的支付路径提前按平台政策确认。
4. 合规层：对照官方政策与开发者后台表单逐项核对，包括敏感权限与数据共享说明。

每层容易漏的点不一样：依赖层常漏的是间接依赖，比如统计 SDK 里顺带集成的广告标识；账号层容易只看供应商文档而不实测；支付层的常见误判是以为接了自己的支付就算完；合规层建议在提审前留出一周改文案和补材料。

哪些能直接复用，哪些必须替换

分界线不是原生还是跨平台，而是这段代码有没有绑死国内服务。业务规则、页面结构、已经在服务端跑通的接口协议通常能复用；凡是与外部的账号、支付、推送、定位、统计发生关系的部分，基本都要按目标市场重接。

• 可以复用：业务逻辑、数据模型、UI 结构、服务端接口协议。
• 需要替换：地图与定位 SDK、推送通道、登录与分享类第三方 SDK。
• 需要新增：目标市场账号登录、统一推送、平台内购、面向当地的隐私弹窗。
• 需要重写文案：隐私政策、权限说明、数据安全表单、商店页面介绍与截图。
• 需要复核：目标系统版本要求、广告标识使用、后台定位等敏感权限的申报口径。

改造量可以按三档做粗略对照，具体落点取决于服务层有没有统一封装：

1. 只补链路：登录与推送已统一封装，只需补邮箱登录、替换推送和合规文案，工作量常见区间是原开发量的 20% 左右，排期约三到五周。
2. 中等改造：支付要换平台内购，地图与推送同时替换，工作量常见区间是原开发量的 30% 到 40%，排期约六到十周。
3. 接近重做：调用散落在各页面、硬编码较多，或产品本身长在国内生态上，服务层基本要重写，周期通常十周以上。

这三档的差别不在代码行数，而在测试与合规的工作量：越是底层替换，越要把回归测试和商店表单重做一遍。

交付现场：先盘点再排期，通常能省下什么

常见的约束是：客户国内版本已上架且在持续迭代，老板希望尽快看到 Google Play 版本，又不接受国内功能停更。经验做法是先用两三天把包内第三方 SDK 与登录、支付、推送链路列成一张表，再和客户确认本期只做登录、推送与合规三处，把平台内购放到下一期。代价是首期功能看起来不完整，好处是不必为赶排期同时改支付，测试面收窄很多。

也遇到过一次反过来：客户坚持首期就把支付一起换掉，结果提审被退回，原因是数据安全表单的申报项与统计 SDK 实际采集项对不上，改申报、改隐私政策、重新打包再提审，整体比原计划晚了一周多。这里的经验区间是：先盘点后动手，通常能省掉一到两周的盲目改造；一旦支付同步替换，排期常见会拉长到六到十周，越早确认越不容易挤压上线窗口。

适用与不适用，边界要先写清

「先复用再替换」适合已经有国内版本、业务逻辑相对稳定、想用较低成本验证海外市场的团队，也适合工具类和内容类这种服务层依赖不深的产品。判断标准可以落到一句话：目标市场的用户，能不能在不额外引导的情况下完成注册、找到核心功能、走通一次付费。三件事有一件走不通，出海改造就还没到位。

不适合的情况也要说明：如果产品本身就长在国内生态上，比如强依赖微信关系链的社交、依赖国内配送网络或本地供给的服务，换壳出海的价值有限，改造量容易接近重做。若目标只是服务海外华人用户，而这批用户仍在使用国内账号与支付方式，先做小范围灰度、只处理商店合规与登录可用性，往往比一次性全量替换更划算。

边界句：如果登录、支付、定位这三条链路里任意一条在目标市场无法闭环，优先做的是把链路打通，而不是先把包传上去，早提审只会把问题暴露给第一批用户。

常见问题

国内版 Android 包直接上传 Google Play，一定会被打回吗？

不一定，但概率偏高。业务代码多数能复用，账号、支付、推送、地图与数据安全表单一般要对齐目标市场，逐项核对后再提审更稳。

出海改造大概要多花多少钱、多久能上线？

常见区间是原开发量的 20% 到 40%，工期常见三到八周，取决于服务层封装程度和是否要新增平台内购，封装差的项目会明显偏上。

iOS 版本出海，和 Android 的改造清单一样吗？

思路一致但清单不同。iOS 侧主要看账号登录、是否走平台内购和各市场的隐私标签；推送通道通常可以继续沿用，不必整条替换。

只改商店文案和后台表单、不动代码，有机会过审吗？

少数不依赖国内账号、支付和推送的工具类 App 有机会。只要核心链路在当地跑不通，光改文案和表单过不了体验这一关。

先上架再慢慢改，风险主要在哪？

风险在差评和账号记录。平台对反复违规有账号层面的处理，建议首次提审前先把登录、支付、隐私三处核对到位。

如果手上已经有一个国内上架的 Android 包，可以先做一件小事：把包内第三方 SDK 列成一张表，逐项标注在目标市场是否可用。这张表基本能决定出海是小改还是重做，也方便用来对齐报价与排期区间。链路没通之前，不建议把上架排在第一步。犀跃公司在移动端定制开发交付中，通常也是先出这份盘点再排期。