用途：优化应用何时、如何、向谁展示评分请求，从而提升商店星级与评分量，并在评分下滑后制定恢复策略。评分既影响搜索排名，也是产品页的转化因素。
平台规则：iOS 使用 SKStoreReviewRequest，Apple 每年最多展示 3 次，展示逻辑由 Apple 控制，调用不保证弹出，界面不可自定义，绝不能在报错、崩溃或受挫时请求；Android 使用 Play In-App Review API，无硬性上限，但频繁调用会被 Google 限流，且无法得知用户是否真的评分。Android 评分永久累积，一次低谷难以恢复；iOS 可按版本重置评分。
核心规则：只向已获得价值的用户请求评分。需要在应用中定义 1 至 3 个“成功时刻”（如完成训练、完成任务、过关、首次交易成功），避免在跳过、失败、同步错误或冷启动时请求。
触发条件：会话数≥3、安装≥3天、至少完成一次激活事件、上次会话无崩溃、当前会话无负面信号、该版本未评过分。建议在触发原生弹窗前先问“Are you enjoying [App Name]?”，选“是”再触发原生请求，选“否”则展示反馈表单。
频率建议：iOS 每版本 1 至 2 次；Android 每位用户每 30 天 1 次；同一会话内绝不重复展示。
恢复策略：定位导致下滑的版本与差评原因，修复后回复所有 1 至 3 星评价并在新版本上线后告知用户，仅向高活跃忠实用户发起评分请求，避免向已留差评者请求。输出为一套评分策略计划，包含现状、成功时刻、预调查开关、触发逻辑、预期结果与恢复计划。
限制：iOS 弹窗次数由系统强制；Android 无法确认用户是否评分；部分预期提升数值（如预调查带来 0.3 至 0.8 星）来自资料所述经验值，实际效果可能因产品而异。