网络超时最危险的误解，是把“没有收到成功响应”当成“对方没有执行”。
本文使用Java 7 与支持事务、唯一约束的关系数据库，代码为设计伪代码。支付系统同时面对用户请求、外部通道和本地账务，三者不共享一个事务。网络异常下必须保留“不确定”状态，并用查询、流水和对账逐步消除差异。
1. 从现象推到机制
请求可能在发送前失败，也可能已到达通道但响应丢失。无幂等约定的写操作不能盲目重发；先查询已有交易，仍不确定则等待通知与对账。重试要有次数、退避和总时间预算，避免故障时放大流量。
图中的四个节点分别表示请求发送、等待响应、主动查询、有限恢复。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
为每次尝试记录业务键、通道请求号、阶段和耗时。下面的流程只适用于支持稳定请求号与查询接口的通道。
1
2
3
4
5
6
7
submit(stable_request_id)
if response_timeout:
result = query(stable_request_id)
if result.is_unknown:
schedule_bounded_query()
else:
apply_verified_result(result)
示例使用虚构订单和金额，不能连接真实支付通道。实现时需要替换数据库访问与验签适配，并明确事务提交点；外部接口的签名字段和响应约定以通道协议为准。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 发送前连接失败 | 可根据协议决定是否重试 |
| 通道完成而响应丢失 | 查询应找到同一交易 |
| 下游连续超时 | 重试流量必须有上限 |
对照 1：发送前连接失败
可根据协议决定是否重试。观察时记录请求是否有可能到达对方。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：通道完成而响应丢失
查询应找到同一交易。观察时记录稳定请求号与通道流水。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：下游连续超时
重试流量必须有上限。观察时记录总预算与每次退避时间。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
客户端超时应短于整体业务截止时间，并给后续查询留下余量。服务端结果未知要明确展示，不能用一个失败标记掩盖待处理交易。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“下游连续超时”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
