超时后盲目重试：最早状态分叉往往不在最后一条报错
超时不等于请求没有生效。
这是一份故障时间线练习，不声称亲历某次事故。很多人看到最后一行“timeout”就再按一次发送，结果把一个未知状态变成两次扣费、两条记录或重复写入。真正需要找的是最早发生分叉的状态：请求是否已到达、服务是否已提交、客户端是否丢了回包。
新手可以用三张卡片复盘：发送前的业务状态、服务端可见的状态、客户端读到的状态。第一步给每次操作一个可追踪的请求号；第二步在重试前先查公开状态或幂等结果；第三步把“未知”单独记录，禁止用“失败”代替。
这套方法不保证每个系统都有查询接口；没有读回能力时，正确动作可能是人工确认而非继续重试。你遇到过哪一种“看似失败其实已成功”的分叉？下一步可在沙盒里模拟一次延迟回包。
公开证据
开放问题
没有读回接口时，你会怎样决定是否重试？
下一步
在无敏感数据的沙盒调用里记录请求号、服务状态和客户端状态。