剩余三秒却再发五秒请求：网关重试前怎样核对总截止时间

重试次数尚未用完，不等于还有时间再发一次。网关排队用了三秒，第一轮用了四秒，即使总预算十秒只剩三秒，若仍按原来的五秒调用超时发出，就已经无法兑现入口的截止时间。这里用毫秒整数和可注入时间线验收发送前的准入决定。

将预算拆成互不重叠的四段

附件每行有排队、先前调用累计耗时、本次退避和本次最小执行预算。十秒预算的第一行分别为两秒、两秒、一秒、五秒，总和正好十秒，允许准入；第二行前三段已用七秒，再需要五秒，拒绝。各列必须来自同一个业务起点，不能把已含排队的elapsed再加一次queue。

本例允许“预计完成恰好等于截止点”，但在截止点才准备发一个需要正时长的调用必然拒绝。第三行排队已经消耗十秒，即使只申请一毫秒也不能发送。第四行只比第一行多一毫秒，同样拒绝。边界比较用小于等于还是严格小于，应先写入契约，再以向量验证，避免审查时各人凭直觉理解。

检查必须放在真正发送之前

只在进入重试函数时算一次remaining，会漏掉等待信号量、退避休眠和获取连接的时间。安全的结构是每段等待都接收同一个绝对deadline，在真正获取发送许可后再计算一次剩余量。不能先把请求投入无人监管的后台队列，然后让入口超时就当作调用已经取消。

参考结果里四个样本只有第一项进入发送，所以上游发送计数是一。拒绝原因应分开记录为队列已过期、退避后不足执行预算或执行预算不足。这样能判断是队列拥塞还是重试策略占用了时间。把所有拒绝统一称为上游超时，会让提供方收到并不存在的故障归因。

不把准入预测当作执行保证

五秒是本地策略要求的最小执行预算，不是模型保证五秒内完成的测量值。允许发送后仍可能超时，也仍需在途取消与资源清理。HTTPX官方把连接、读取、写入和连接池等待作为不同超时阶段，配置其中一个并不会自动替代入口总预算。

实际程序宜使用单调时钟保存进程内deadline；跨进程传递时要设计清晰的剩余预算或绝对时间协议，不能把一个进程的单调时间直接发给另一台机器比较。收尾阶段若需要持久化状态，也应留独立余量。本文没有发出网络请求，拒绝前零发送是参考器的可复核断言；它不能反向证明过去已经超时的那次真实请求从未在上游执行。验收上线适配时，发送计数和截止原因必须一起采集。

配套样本与复核入口

下载本篇独立合成输入和实验运行器。上述文件放在同一目录后运行 python run_lab.py C003。完整运行需要全部四十四份输入及相关配置。结果中的method区分离线计算、静态参考检查与回环实测，不能把前两者当成真实网关已通过。

补充文件：c003-timeline.csv。合成表供独立复算，配置片段是否实跑以正文说明为准。

资料核对日期：2026-10-24。官方依据1；官方依据2。

与本站相关基础教程的区别：旧文解释连接和读取超时；本文验收服务端统一deadline的准入算法及排队、退避、调用三段占用，不重复SDK超时配置。