请求失败后要不要重试：按操作类型决定，而非靠刷新次数

互联网服务响应异常时，“再点一次”看似自然，却可能让问题更复杂。一次请求失败不一定意味着服务没有收到它：网络中断可能发生在发送前、处理中或返回结果时。尤其是创建、保存、发送和支付类动作，盲目重试可能留下重复记录。因此，是否重试应取决于操作类型、可见结果和当前状态，而不是取决于已经刷新了多少次。

先区分读取与写入

查看页面、搜索记录、读取文档通常不改变数据，有限复试的风险相对较低；提交表单、创建任务、发送消息、修改设置则可能写入结果，应格外谨慎。即使页面显示超时，也不要假设写入未发生。先检查列表、历史记录、通知或结果页是否已有对应条目，再决定下一步。关于重复操作的细节，可阅读服务不稳定时为何不要连续提交：识别重复操作的风险。

设置间隔，避免短时间连发

对于可安全确认的读取请求，间隔一段时间再复试通常比连续刷新更有意义。这样既能观察状态是否变化，也不会把本地缓存、临时网络波动和服务端延迟混在一起。若状态信息已说明正在缓解问题，仍应以其后续更新时间为参考，不要自行推断已经完全恢复。

先查结果，再考虑替代路径

写入动作失败后，第一步应是寻找是否已经产生结果；第二步是查看状态更新是否提示相关功能受影响；第三步才是评估是否有经过允许的替代流程。替代路径应记录清楚，避免日后恢复后又重复补录。恢复阶段还需要检查最终结果，观察恢复进度的四个检查点：别把页面可打开当作全部正常说明了为何不能只看入口可访问。

用明确的停止条件保护工作

事先约定“出现同类错误两次后暂停写入”“状态未知时不做批量操作”等停止条件，能减少现场判断压力。重要任务可先保存在本地或草稿中，等待服务稳定后再执行。若异常恰好发生在维护窗口，也应先确认公告所述范围和时段，相关安排可参考看到维护与异常公告后，怎样安排关键在线任务。

恢复后做一次完整核对

重试成功并不表示旧请求一定没有留下痕迹。应查看是否存在重复条目、顺序错乱或通知延迟，并记录最终确认时间。若没有收到应有提示，不妨按状态恢复了却没收到通知：按时间和结果排查通知延迟逐步区分延迟与未完成。

结论是：失败后的首选不是立即重试，而是识别操作类型、查验结果、等待状态变化，并在有依据时进行一次受控复试。