上架前 10 个关键检查点（按拒审高频排序）
经验结论很简单：Google Play 不是“看你写得多漂亮”，而是“能不能按你的说明复现”。优先保证三件事一致：商店页声明、应用内实际行为、审核员可验证路径。
1) 开发者账号与付款信息
账号主体信息、联系方式、付款方式配置完整；团队协作权限按最小权限分配。新账号要预留更长审核时间与更严格的合规检查。
2) 包体与版本信息
AAB/APK 可正常安装运行；版本号、包名、签名与渠道一致；目标 SDK 与核心依赖已完成回归验证。
3) 隐私政策 URL
隐私政策可访问、内容与实际数据行为一致；应用内也能找到入口，且入口路径对审核员友好（不依赖不可用账号/地区）。
4) Data Safety 对齐（最常见：mismatch）
Data Safety 填写与实际采集、共享、存储行为一致；账号删除、数据删除等路径可复现；重点排查：第三方 SDK 是否产生与你声明相反的数据行为。
5) 权限最小化与用途/触发时机
移除非必要权限；权限申请时机、权限用途说明与真实功能一致；敏感权限建议准备“触发页面+用途说明+截图证据”。
6) 目标受众与内容分级
目标受众、内容分级与应用内容一致；如有 UGC、社交或金融内容，补齐对应的合规提示与内容治理策略。
7) 商店素材与元数据真实性
标题、描述、截图、图标、宣传语与应用实际功能一致；避免夸大、误导性词汇与不实截图，尤其是“赚钱、免费领、官方授权”等高风险表达。
8) 登录/订阅/付费路径可验证
如需登录或订阅才能体验核心功能，准备可用测试账号与最短复现路径；订阅条款、价格、取消方式与应用内入口一致。
9) 外链与下载行为
避免引导外部下载、绕过支付或强引流；如必须使用外部链接，说明用途并确保不会触发“deceptive behavior/误导行为”。
10) Review Notes 与证据包
准备 Review Notes：问题点说明（如有）、改动摘要、测试账号、复现步骤、预期结果；能让审核员一次看懂并验证。
如果你已经被拒过一次，第二次提交的关键不是“写更多解释”，而是“把验证成本降到最低”。路径越短、账号越可用、预期越清晰，通过率通常越稳。
Review Notes 模板（可直接复制粘贴）
App name/version: [Your App] / vX.Y.Z / Production
Test account: [email] / [password] (Region: [xx], 2FA: [yes/no])
Validation path:
1) Install → open app → [tap “…”]
2) Login with test account → [go to feature X]
3) Trigger permission [CAMERA/LOCATION] on [screen Y] → Expected: [reason/use-case]
Expected result: [what reviewer should see]
Notes:
- Privacy policy entry: Settings → Privacy Policy
- Data deletion/account deletion: Profile → Delete account → [steps]
- If access is geo-limited: use [country] / [method]
Play Console 对应位置（快速定位）
这块是给项目负责人用的：拒审邮件来了，别先“乱改一通”，先把 Console 里对应入口定位清楚，再对照你的声明与应用内行为逐项核对。
Data Safety
Play Console → 政策与计划 → 应用内容（App content）→ Data safety。
账号删除/数据删除
Play Console → 应用内容（App content）相关项；同时确保应用内路径可复现，并在 Review Notes 写清入口与步骤。
隐私政策 URL
Play Console → 商店发布（Store listing）相关项；同时在应用内提供可点击入口（常见做法：设置页 / 个人中心页）。
权限与敏感权限说明
Play Console → 应用内容（App content）与提交版本检查；应用内权限弹窗的“用途解释”与触发时机要一致。
目标受众与内容分级
Play Console → 应用内容（App content）→ 目标受众与内容（Target audience & content）。
商店素材与元数据
Play Console → 商店发布（Store listing）：标题、短描述、完整描述、截图、功能宣称与实际行为一致。
App access / 无法验证
Play Console → 应用内容（App content）→ App access（如有）；准备可用测试账号，并把最短复现路径写进 Review Notes。
拒审邮件先看这 4 个信号
Unable to verify / Cannot access这是“验证失败”而不是“功能失败”。先补测试账号、最短路径、预期结果，再谈改功能。
Data Safety mismatch先做“声明—SDK—实际行为”三方对齐。高频根因是第三方 SDK 行为与你的填写不一致。
Deceptive behavior / Misleading优先排查商店页与应用内不一致：夸大承诺、诱导点击、外链下载、绕过支付、截图与实际不符。
Policy scope 不清把“触发点”写清：哪个页面、哪个按钮、哪个权限、哪条路径触发；再给出改动摘要与证据截图，避免来回问答。