那次超时的提交真的保存了你的工作吗？

按钮转着圈，标签页报出错误，你花了十分钟填好的表单不见了。你不知道的是，连接断掉之前那次写入到底有没有成功。把这种不确定当成失败，正是重复评论、重复下单和反复提交工单的来源。

按固定顺序恢复：留住文本，找到结果，然后才判断是否允许再次提交。

从文本和时间戳开始

在碰任何别的东西之前，先把页面里的内容复制出来，包括浏览器还留在输入框里的草稿。记下时间、你所在的页面和你做过的操作，因为正是这三样细节让后续排查成为可能。如果标签页还开着，就让它在读完网络条目之前一直开着。保存文本不花任何代价，丢掉它却要赔上整个任务。

然后区分你真正能观察到的两种故障形态。请求中途断开的连接，和用错误码作答的服务器，在网络面板里长得不一样；只有后者才透露应用本身做了什么决定。

在应用自身的视图里找结果

重新加载能显示结果的读取视图：评论列表、订单历史、工单队列，或者你正在编辑的那条记录。按账号、目的地、时间和内容去比对，而不是只看最新一条，因为别人可能在你之后也写过。对后台任务，去查已有的引用和它的状态，而不是新建一次操作来当作连通性测试。

如果结果在那里，事情就结束了，错误属于回复链路而不属于写入。如果不在，请保留应用还没有落库的可能：排队中的任务、延迟的读取视图或者落后的副本，都可能把一次成功的写入暂时藏起来。

在下结论之前，给它一个明确的第二次查看，并记下两次检查的时间。相隔二十秒的两次检查，比相隔十分钟的两次检查弱得多。

判断第二次提交是否安全

答案取决于操作本身，而不是你的耐心。HTTP 把可以带着相同预期效果重复的方法，与不能重复的方法分开，并建议不要对第二类做自动重试，除非已知其语义允许。发表评论、下订单和发起付款通常属于第二类，所以第二次看似成功的点击，说明不了第一次的任何事。

如果你在维护客户端，就用 API 文档里写明的重试或幂等机制，并把它绑定到同一个逻辑操作上，而不是每次尝试都生成新键。用于追踪的请求标识符并不是去重键，除非服务器确实那样对待它。

curl -i -X POST https://api.example.net/v1/orders \
  -H "Idempotency-Key: 6f1c2a94-3b7e-4a10-9c22-5d0e8f7b1a63" \
  -H "Content-Type: application/json" \
  --data @order.json

只有服务把这个键与操作一起存下来，并在重复时返回最初的结果，它才有用。在依赖它之前，先在一个预发布端点上验证这种行为。

再次按下任何按钮之前先留下证据

保留网络条目，而不是错误的截图。请求方法、URL、响应或者超时，以及发生的时间，才是管理员能与应用记录对照的东西。只有当随后把副本里的 cookie、授权头和任何隐私内容都去掉时，才把条目录成命令导出或复制。别动你自己的会话，也永远不要把抓到的带凭据请求当作捷径重放。

向服务负责人问一个具体的问题：这次内容在这个时间点的操作成功了吗，有没有对应的引用？这个问题有答案，而网站是不是坏了没有。

这套动作的目的是确认操作恰好发生了一次。你能关掉的错误提示，和你能信任的记录不是一回事，而在提交任何东西之前，你需要的是后者。