以下为 Google Gemini 整理，仅略作修改。

这份表格是为了帮助你和团队在按下“提交审核”按钮前的最后 5 分钟内，进行一次**“保命级”**的快速扫描。建议将其复制到 Excel 或飞书文档中，每次发版前逐项打钩。

✅ 双端 App 发布前核对清单 (2025 运维版)

1. 🛠️ 核心技术与包体检查 (Technical & Build)

确保上传的包是“对的包”，且能正常运行。

检查项Android (Google Play) 关注点iOS (App Store) 关注点运维操作/备注
环境配置必须指向 Production (正式环境)必须指向 Production (正式环境)严禁把连接测试服务器包发上线
Version Name如 1.2.0如 1.2.0建议双端保持一致，便于运营宣传
Version Code / Build必须 > 上个版本 (如 102 -> 103)必须 > 上个版本 (如 202501 -> 202502)忘记递增会导致上传失败
Target SDK / iOS SDKAPI Level 35 (Android 15)使用最新的 Xcode 编译Android 低于 API 34/35 必被拒
架构支持必须包含 64-bit (arm64-v8a)标准 arm64Android 必须查，否则无法上传 AAB
包体格式.aab (Android App Bundle).ipa不再接受 APK
硬性合规文件Data Safety 声明Privacy Manifests (隐私清单)iOS 缺少清单或描述不符会直接报错

2. 📋 商店元数据与合规检查 (Metadata & Compliance)

确保审核员能看懂，且没有政策风险。

检查项关键检查点风险等级
测试账号 (Demo Account)最容易被遗忘！ 确保后台填写的账号/密码当前有效，且账号内有数据（不是空白号）。🔴 高危 (100% 拒审)
隐私政策 URL点击链接，确保网页能打开，且内容包含最新的公司实体名称。🔴 高危
版本更新文案 (What's New)检查是否包含多语言（如英文、中文）。切记： 不要写“修复了安卓特有的Bug”在 iOS 文案里，反之亦然。🟠 中危
截图 (Screenshots)Android： 状态栏不要出现 iPhone 特征。
iOS： 状态栏不要出现 Android 图标，不能有透明背景。		🟠 中危
分级问卷 (Rating)如果新版本加了“即时聊天”或“赌博相关”功能，必须重新填写分级问卷。🟠 中危
出口合规 (Export Compliance)iOS 专用： 首次选择构建版本时，需确认加密算法合规性（通常点 Yes -> Yes）。🟡 低危 (但这步不做没法发)

3. 🚀 运维发布策略配置 (Release Strategy)

确保发布过程可控，防止灾难性事故。

检查项操作动作推荐配置
灰度/分阶段发布Android: 设定 Update rollout percentage
iOS: 勾选 Phased Release for Automatic Updates		Android: 5% 起步
iOS: 默认 7 天周期
发布时间点确认是 "Manual Release" (手动发布) 还是 "Auto" (自动)推荐 手动发布。审核通过后，由运维在业务低峰期（如凌晨）点发布。
后端兼容性确认新版 App 依赖的 API 接口是否已上线？先发后端，后发客户端。防止新 App 请求不到新接口报错。
强制更新开关如果是强更版本，确认配置后台的强更开关逻辑是否正确。务必慎用强更，除非有重大安全漏洞。

🆘 紧急情况预案 (如果出事了怎么办？)

作为运维，发布后必须盯着 Crashlytics (崩溃监控) 和 用户反馈 至少 1 小时。如果出现重大问题：

  1. Android 端：
    • 点击 Halt Rollout (暂停发布)。
    • 此时只有已经下载的那 5% 用户受影响，其他人还是旧版本。
    • 修复： 打包一个新的 VersionCode，上传，直接覆盖发布。
  2. iOS 端：
    • 点击 Pause Phased Release (暂停分阶段发布)。
    • 如果有严重 Crash：
      • 方案 A (回滚)： App Store 不支持直接“回滚”到旧版本。你只能把旧版本的代码重新打包一个新 Version 号上传（耗时久）。
      • 方案 B (下架)： 极端情况下，在后台将 App "Remove from Sale"（下架），但这会导致所有新用户搜不到 App，慎用。
      • 方案 C (加急)： 修复 Bug 提交新包，申请 Expedited Review (加急审核)，理由填 "Critical Bug Fix"，通常 12 小时内处理。