3. 超时机制详解
在支付系统中，“超时”并不是一个简单的计时器到期事件，而是贯穿客户端、网关、支付服务、渠道方与账务系统的状态判定问题。理解超时机制，是设计异步回调与最终一致性方案的前提。本节将从定义、成因、时间设置策略以及客户端与服务端处理差异四个层面展开。
一、支付超时的定义：三种“超时”不能混为一谈
工程实践中，支付超时至少包含三类语义，若不加区分，极易导致重复支付或订单状态错乱。
- 请求超时：客户端或服务端发起一次网络调用后，在约定时间内未收到响应。它描述的是“通信未完成”，不代表支付失败。
- 订单超时：订单创建后，在业务规定时间内用户未完成支付，系统主动关闭订单。它描述的是“业务机会窗口关闭”。
- 渠道超时：支付渠道在规定时间内未返回明确支付结果，系统进入“未知态”，必须依赖查询或异步回调来确认最终状态。
关键认知：请求超时是通信层概念，订单超时是业务层概念，渠道超时是状态机概念。三者时间阈值不同、处理主体不同、补偿手段也不同。
二、超时产生的原因：从网络到业务的全链路分析
支付链路通常为：客户端 → API 网关 → 支付服务 → 渠道适配层 → 第三方渠道 → 银行/清算网络。任一环节异常都可能表现为超时。
| 层级 | 典型原因 | 表现特征 |
|---|---|---|
| 客户端 | 弱网、DNS 解析慢、页面切后台 | 用户侧提示超时，但服务端可能已受理 |
| 网关/负载 | 连接池耗尽、限流、TLS 握手慢 | 大量请求在入口处排队超时 |
| 支付服务 | 下游依赖阻塞、GC 停顿、线程池满 | 响应时间抖动，部分请求超时 |
| 渠道方 | 渠道系统维护、银行通道拥堵 | 返回“处理中”或直接读超时 |
需要特别注意的是：超时是结果，不是原因。排查时应沿着调用链逐段测量耗时，而不是只盯着最外层报错。
三、超时时间设置策略：分层设定，逐级收敛
超时时间不能“一刀切”，而应遵循“外层大于内层、业务大于通信”的原则，形成逐级收敛的预算体系。
- 客户端超时：通常设置为 10～30 秒，需覆盖用户感知与网络波动，但不宜过长，避免用户长时间等待。
- 网关超时：略大于后端服务超时，例如后端 5 秒，网关设 6～8 秒，防止网关先于服务端断开。
- 支付服务调用渠道：根据渠道特性设置，一般 3～10 秒；对“处理中”状态应快速返回，而非死等。
- 订单超时：由业务决定，常见 15 分钟、30 分钟，需与库存、优惠券释放策略联动。
推荐做法：为每个下游依赖设置独立超时，并配合重试预算。例如渠道查询接口超时 2 秒，最多重试 2 次，总耗时不超过 6 秒。
# 示例：支付服务调用渠道的超时配置
channel:
connect-timeout: 1000ms
read-timeout: 5000ms
max-retries: 2
retry-backoff: 200ms
order:
expire-after: 15m
close-check-interval: 30s
四、客户端与服务端超时处理差异
这是最容易出问题的部分。客户端超时后，用户看到“支付失败”，但服务端可能已经成功扣款。两者对超时的处理逻辑必须解耦。
- 客户端：超时后应提示“支付结果确认中”，并提供“查询订单”入口，而不是直接判定失败。客户端不应自行修改订单状态。
- 服务端：超时后进入“未知态”，通过主动查询渠道 + 等待异步回调来确认最终状态，并驱动订单状态机流转。
- 状态机：订单状态应包含“支付中/未知”，只有收到渠道明确成功或失败后才迁移到终态。
常见误区：客户端超时即调用“关闭订单”接口。若此时渠道已扣款成功，将导致用户已付款但订单被关闭，引发投诉与对账差异。
下面用一张状态与信号关系图，展示超时发生后客户端、服务端与渠道之间的状态判定路径。
五、案例复盘：一次“客户端超时导致重复支付”的排查
某电商大促期间，用户点击支付后客户端 10 秒超时，页面提示失败。用户重新下单并支付成功。但随后渠道异步回调显示，第一笔订单实际已扣款成功，形成重复支付。
- 根因：客户端超时后直接引导用户重新下单，服务端未将原订单置为“未知态”并继续确认。
- 修复：客户端超时改为“结果确认中”；服务端对未知态订单启动查询补偿；订单关闭前必须确认渠道无成功记录。
- 经验：超时处理的核心不是“快速失败”，而是“可靠确认”。
最终一致性视角下，超时只是触发补偿的信号。真正决定资金安全的，是服务端能否在超时后持续追踪渠道状态，直到订单进入明确终态。
综上，支付超时机制的设计要点可归纳为：区分三类超时语义、分层设置时间预算、客户端只做提示不做裁决、服务端以未知态驱动查询与回调补偿。只有把超时当作状态确认的起点，而非终点，才能为后续异步回调与最终一致性打下可靠基础。