提供可执行的解决方案
别名: 错误恢复 · 修复建议 · 下一步 · 恢复动作
概念解释
错误说明之后必须有路径：重试、修改字段、换支付方式、申请权限、恢复备份、联系支持或稍后自动同步。可执行方案（error recovery）应尽量变成按钮、链接、预填值或自动修正，而不是让用户自行推断管理流程。它在这一组里排在"说明问题"和"定位问题"之后，因为恢复动作要有意义，前提是用户已经知道发生了什么、发生在哪——恢复方案脱离了前两条单独出现，往往是一句空洞的"请稍后重试"。
机制
用户失败之后的真实目标从来不是弄懂系统的内部逻辑，而是尽快回到任务本身。把下一步做成一个可点击的动作，等于替用户完成了"从诊断结论到具体操作"这一步转换，减少他们需要记住规则、切换页面、自己组织操作顺序的负担。这个转换的价值在系统已经知道失败类型时被放大：如果系统能判断出是余额不足还是网络超时，它就能分别提供"更换支付方式"或"重试"这两个语义完全不同的动作，而不是给一个通用按钮让用户自己猜；系统甚至可以主动保存已填内容、跳转到出错的具体位置、推荐替代资源，把恢复变成一次连续动作而不是从头再来一遍。反过来，没有行动路径时用户的典型反应是三种代偿行为：反复重试同一个必然失败的操作、直接放弃任务、或者把问题升级为一张支持工单——三者都比一个正确的恢复按钮昂贵。
边界
建议必须诚实且与权限匹配，不能制造"看起来有路径、实际走不通"的假象——比如提示普通用户"联系管理员开通权限"，却没有给出可复制的错误上下文，管理员收到求助后根本无从查起，这种恢复路径等于没有。也不能默认自动重试所有失败请求，涉及扣款、发送、写入这类有副作用的操作，重复执行可能造成重复扣款或重复发送，自动重试必须先确认操作是幂等的。如果失败原因掌握在外部方手里、系统本身无法加速恢复（比如等待第三方支付渠道的对账结果），诚实的做法是说明预期等待时间、后续通知方式和当前数据处于什么状态，而不是提供一个"重试"按钮制造还能做点什么的错觉。当同时存在多个可选恢复方案时，要清楚标出它们的差异和各自后果，避免用户在不了解代价的情况下选中了成本最高的一个。
怎么落地
- 为每一类错误预先定义首选、替代和兜底三级恢复动作，并把它们做成错误组件的标准部分，而不是每次由前端临时决定。
- 恢复过程中保留用户已填的输入、上传的文件和已设的筛选状态，让用户能从失败点续接，而不是被要求全部重填一遍。
- 在恢复入口旁提供"复制诊断详情"的按钮，方便用户求助时能带上完整上下文，减少支持人员来回追问的轮次。
- 验证办法：对每一个恢复按钮演练四种真实结果——恢复成功、重复点击、当前用户无权限执行、以及操作只完成了一部分——确认这四种情况都有对应的、不同的反馈，而不是共用同一句"处理中"。