PR Review Assistant is an inte…

# PR Review：订单超时 30s→15s

> 重要前提：我无法直接访问 xxx-order-service 仓库和该 PR 的实际代码，以下是基于“缩短订单超时时间”这类改动的通用 Review 框架。请对照你的实际 PR 逐项检查。

一、改动本身需要确认的点

• 改动范围：确认是只改了配置常量/配置中心，还是硬编码散落多处；是否有遗漏的 30s（如定时任务扫描、兜底关闭逻辑）导致不一致
• 语义确认：这个“超时”具体指什么——下单接口响应超时、支付等待超时、还是订单取消超时？不同语义风险完全不同

二、高并发场景下的主要风险

1. 超时误杀风险（最大风险）

• 高峰期下游（库存扣减、支付渠道）响应变慢时，15s 更容易触发超时，导致订单被取消但下游实际成功
• 检查点：超时后的补偿逻辑——是否查询下游状态再决定取消，还是直接置失败？直接失败可能造成“钱扣了单没了”

2. 幂等与状态一致性

• 缩短超时会提高“取消 vs 支付成功”竞态概率，重点看：取消回调与支付回调并发到达时，状态机是否有幂等保护、是否可能出现单边账

3. 下游联动未同步

• 支付渠道的最小有效期通常远大于 15s；如果这是“待支付订单关闭时间”，需确认支付回调晚于关单时的处理（自动退款？人工介入？）

4. 重试放大

• 超时变短 → 客户端/网关重试概率上升 → 高并发下重试流量放大，可能压垮本就变慢的下游。检查重试策略是否有退避与熔断

三、建议的验证动作

• [ ] 压测对比：模拟高峰 RT（P99）与 15s 的余量是否 ≥ 3~5 倍
• [ ] 灰度发布：按小流量比例逐步放开，观察超时取消率、支付回调迟到率
• [ ] 配置兜底：走配置中心热更新而非发版，便于紧急回滚
• [ ] 监控告警：新增“超时取消量”、“取消后支付成功数”两个指标

四、结论

改动方向本身常见且合理，但是否可合并不取决于改了什么，而取决于补偿/幂等链路是否完备。若取消逻辑是“先查证再取消”且有自动退款兜底，风险可控；若是简单置无效，建议先补链路再上线。