用户反馈“更新后打不开”，先不要只给出“已经回滚”的答复。维护人员需要知道出问题的是哪个客户端版本、哪些设备、哪个操作，以及服务端是否同时改过。客户端安装包、服务端接口和业务配置分别由什么机制发布，决定了恢复能做到哪一步。
暂停分阶段发布，不等于收回已安装版本
Apple 的分阶段发布针对符合条件且开启自动更新的用户逐步分发更新；用户仍然可以主动从 App Store 下载。官方允许暂停分阶段发布，但这个操作控制的是后续分发，不能据此宣布已安装新版本的用户已经恢复。Apple 分阶段发布说明
因此，维护约定不能只写“异常时回滚”。应分别写明：谁有权限暂停分发，谁判断已安装版本的影响，是否需要修复包，以及旧客户端能否继续访问接口。上述 Apple 机制只适用于相应 App Store 发布场景，其他应用市场应逐一核实自己的规则。
暂停不是无限期的观察窗口
Apple 当前规定，分阶段发布可以多次暂停，但累计暂停时间最多为 30 天；恢复时会接着暂停前的发布进度继续，并非重新从第一天开始。维护负责人应记录已经暂停的时间与当前进度，在恢复前确认故障影响和修复情况，不能把暂停按钮当作可以无限延后的处理方案。Apple 暂停与恢复规则
操作权限也应在交接时落实：该功能要求 Account Holder、Admin 或 App Manager 角色。多搭建议事先确认具备相应权限且能访问该应用的负责人，并留下故障时的联系路径，避免开发已经定位问题，却无人能够操作发布。上述时间限制是平台规则；记录进度与落实负责人是项目维护建议，不代表必须等待暂停期限用完才处理故障。
下架再上架，能接着原来的分阶段进度吗？
不能把下架当作另一种暂停。Apple 当前说明，在分阶段发布期间将应用移出销售范围，会停止分阶段发布，该版本之后不能再次使用这一机制；应用恢复上架时，会立即面向所有用户可用，不论下架前推进到什么比例。开发者会员资格到期导致的下架也属于这一情况。若要重新进行受控的分阶段发布，官方要求将该版本设为不可下载，再提交启用分阶段发布的新版本更新。Apple 下架与恢复上架说明
因此，负责人在决定下架前，应核对当前分发状态、下架原因和恢复后的覆盖范围，并与开发确认是否需要准备新版本。这里的“所有用户可用”不等于所有设备会立即安装，也不表示故障已经修复。恢复计划仍要包含受影响用户的处理路径，不能只记录一个重新上架时间。
先把一条用户反馈变成可定位的事件
客服可以先收集发生时间、APP版本号、手机系统、具体操作和错误提示；有业务单号时，通过约定的工单渠道交给维护人员。不要让用户提供密码、短信验证码，或把完整业务资料发到公开群里。
开发人员再把反馈与崩溃记录、接口日志对照。Crashlytics 可以汇总崩溃并提供排查信息，但是否适合接入，要根据项目已有监测、平台与数据处理要求决定；本文不把接入某个工具作为恢复服务的前提。Firebase Crashlytics 文档
能打开APP却无法提交订单，与启动即崩溃需要不同证据。前者应继续检查请求和业务状态，后者优先定位客户端异常。没有崩溃记录也不代表业务流程正常，仍应复现用户实际失败的步骤。
有崩溃反馈，报告却无法定位代码怎么办？
如果项目的 iOS 端已使用 Crashlytics，维护人员还应检查对应构建的调试符号文件（dSYM）。这些文件帮助把崩溃信息还原为可读报告；官方文档说明，自动上传失败时可能出现 Missing dSYM 提示，应核对文件是否生成、上传配置是否正确，并按缺失文件的 UUID 查找和补传。Firebase 符号文件排查指南
多搭建议把“发布版本、构建编号、归档位置、符号文件处理结果”纳入维护交接，避免只留下安装包。出现缺失提示时，由掌握构建归档的开发人员接手，不让客服要求用户反复安装来解决符号文件问题。补齐符号只是在恢复诊断能力，并不等于崩溃已修复；仍须回到受影响版本复现、定位原因并验证修复结果。其他平台和监测工具应按各自文档核查，不直接套用 dSYM 流程。
恢复动作要按故障位置选择
以下是多搭建议用于项目交接讨论的分工示例，不是应用商店规定，也不是统一响应时限。
| 已确认的问题 | 可讨论的处理动作 | 恢复前必须确认 |
|---|---|---|
| 新客户端启动崩溃 | 暂停扩大发布，定位代码并准备修复版本 | 已安装版本用户怎样获得修复，不能只测试新安装 |
| 新旧客户端调用接口结果不同 | 核对接口兼容，评估恢复服务端版本或临时兼容 | 老版本和新版本都能完成原有流程 |
| 某个新增功能异常，主流程仍可用 | 若项目已有可验证的功能开关，评估暂时关闭入口 | 关闭后没有留下无法完成的订单或表单 |
| 数据已经写入错误状态 | 先保留证据，核对受影响记录与修复方案 | 修复权限、重复执行风险及业务人员确认结果 |
不要把未设计过的功能开关当作随时可用的补救能力。恢复服务端版本前，也要检查数据结构是否仍兼容；代码能够启动，不等于历史数据可以安全处理。
维护约定应区分认领、缓解与修复
认领表示已有负责人接手；缓解表示影响暂时受控；修复表示原因已处理；关闭还需要验证结果。双方应按服务时间、用户影响和实际支持资源约定这些节点，避免把“收到反馈”记成“问题已解决”。
每次处理保留受影响版本、判断依据、已采取动作和下一次反馈时间。新功能需求另行排期，避免在故障处理中顺带改动无关流程。需要讨论费用与阶段交付时，可结合APP开发里程碑与验收划清维护和新增工作。
怎样确认已经恢复？
在受影响的设备与版本条件下重新执行原失败操作，核对界面结果与后台业务结果，再观察相关错误是否继续出现。修复包可下载、测试机通过、用户实际恢复是不同状态，应分别记录。若仍有用户停留在受影响版本，就继续保留处理入口，不提前把事件写成全部关闭。