上架前 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 不清把「觸發點」寫清：哪個頁面、哪個按鈕、哪個權限、哪條路徑觸發；再給改動摘要與證據截圖，避免來回問答。