网络不确定状态下的前端反馈

读请求失败通常比较简单：没有拿到数据，可以提示重试。写请求复杂得多。用户点击提交后，如果前端超时或断网，服务器可能已经处理成功，也可能没有收到请求。此时如果直接提示“失败”，用户可能重复提交；如果直接提示“成功”，又可能掩盖实际失败。

一、把“不确定”作为独立状态

很多前端只有成功和失败两个分支，这不够。写请求遇到超时、连接中断、响应丢失时，应该进入“结果不确定”状态。文案也要表达清楚：当前无法确认操作结果，请刷新或稍后查看。对于可能造成重复后果的操作，要临时锁定按钮，避免用户连续触发。

二、用现有业务状态确认结果

如果页面能通过刷新列表、读取详情或检查业务记录确认结果，优先使用现有读取接口。比如提交后不确定，可以重新获取当前对象状态；删除后不确定，可以检查列表是否还存在；兑换后不确定，可以读取积分和记录。确认动作要克制，不能为了每个请求都增加复杂链路。

三、重复操作风险要提前说明

有些操作重复提交影响小，有些会造成扣分、扣库存、重复创建。风险越高，越要在不确定状态下限制继续操作，并提供刷新确认。对于低风险操作，可以允许用户重试，但也要说明可能发生的结果。

• 写请求要区分成功、失败和结果不确定。
• 不确定状态下避免直接鼓励重复点击。
• 能用现有读取接口确认时，优先刷新确认。
• 文案要说明用户下一步应该做什么。

前端处理网络不确定态，重点不是把所有异常自动收口，而是让用户不被误导，让业务结果尽可能可确认。