yml2213
67f0b28ab6
按"锁单优先、支付从容"放宽支付时序，发布0.3.4
设计前提（此前被我自己违反过一次）：锁单一旦成功就占住了库存（斗鱼锁单有效期 300 秒），
支付晚几秒没有任何损失，所以支付环节不该抢时间——斗鱼对"锁单→支付"有最短间隔，
打得太密只会收到"您点击太快"、把账号往风控上推。
- 首次支付等待 2.3-3.0s → 2.5-3.5s，给实测阈值 (1.68s, 2.1s] 留更足余量
- 支付退避阶梯全面放缓（不再追求快重试）：
在途 300ms→1s 改为 500ms→2s；频控 800ms→2s 改为 1.5s→4s；其它 400ms→1.2s 改为 800ms→2.5s
- 单笔支付总预算 120s → 180s：仍远小于锁单 300 秒有效期，但足够扛住两次 10-03 级别的
服务端堵塞，同时把请求数减半
- 把这条设计前提写进 payLockedOrder 与支付阶梯的注释，避免以后又被当成"浪费"优化掉
- 新增 TestFirstPayDelayStaysAboveServerMinimum：断言首次支付等待不低于实测阈值 2 秒、
等待区间合法、总预算大于首次等待上限
- 设置页补充说明：锁单优先、支付晚几秒无损失，以及支付重试上限改为 180 秒
确认既有架构已经满足该前提（无需改动）：每账号独立循环，一个账号在支付时其它账号继续锁单；
并发额度只按单次请求发放，支付等待期间不占额度；75 秒窗口只限制发起新锁单，不限制支付；
已锁单的账号不再发起新锁单以免重复下单。
2026-10-03 19:43:56 +08:00
..
2026-09-30 20:35:44 +08:00
2026-10-03 19:33:14 +08:00
2026-10-03 19:33:14 +08:00
2026-10-03 19:09:19 +08:00
2026-10-03 19:43:56 +08:00
2026-07-29 13:19:43 +08:00
2026-10-03 19:42:00 +08:00
2026-10-03 19:43:56 +08:00
2026-08-08 17:40:16 +08:00
2026-10-03 19:09:19 +08:00
2026-07-29 12:33:16 +08:00