上架前程式碼稽核：我們實際檢查什麼

許多團隊把「能編譯、能跑通主流程」當成上架門檻，卻忽略商店審核與真實裝置上的長尾風險。上架前稽核不必全面重寫，而是用有限時間鎖定最可能阻擋發布或傷害評價的問題。

我們通常先看崩潰彙整：同一堆疊是否反覆出現、是否集中在特定 OS 版本或裝置。接著比對 Info.plist / AndroidManifest 與實際權限使用是否一致，並確認隱私政策連結與資料蒐集說明對得上。

第三層是發布流程本身：版本號遞增規則、簽章金鑰是否有人可接手、熱修復或強制更新通道是否受控。這些項目寫進檢查清單後，產品與工程就能用同一語言決定「現在發」或「再等一週」。

若時程緊，至少完成：主路徑手動回歸、崩潰 Top 5 分流、權限與商店截圖文案一致性、以及一份書面放行條件。其餘技術債可排進下一迭代，但要標註為已知風險而非遺漏。