一个页面顺序调用三个接口，每个都允许等待十秒，最终用户可能等待远超单个接口的预算。超时不应只是一组互不相干的常量，而应从用户任务的整体截止时间向下分配。
本文使用 fetch 调用上游，数字只是示例配置，不代表推荐生产值。实际预算要根据服务目标、网络条件与调用依赖确定。
用一个用户任务分配预算
假设搜索接口先读取索引，再补充摘要，最后生成响应。总等待目标是一个整体约束，不是三个步骤各自获得相同最大值。为响应序列化和网络返回保留余量，再分配必要上游与可选补充。索引不可用就无法完成搜索，摘要不可用可能仍能返回标题和链接。只有先标记必要性，预算耗尽时才能决定失败还是退化。
整体截止时间可以从请求开始时确定，每一步计算剩余时间，而不不断创建新的完整窗口。若调用者传来更短截止，需要验证来源和边界，再取更早截止，不能允许任意输入延长系统上限。服务间传递期限时考虑时钟差异，局部测量耗时优先使用适合单调计时的 API。日历时间适合记录事件，不一定适合计算持续时间。
假设第一步已经用了大部分预算，第二步即使通常很快，也不能再独占原本总时长。可以选择跳过可选补充，或用剩余期限调用。数字应来自真实服务目标和测量，示例只用于说明分配，不将某个固定三秒推荐给全部产品。用户能容忍的等待与平台允许的执行时长也是两个约束，应用要在前者内表达结果。
const controller = new AbortController();
const timer = setTimeout(() => controller.abort(), 3000);
try {
const response = await fetch(upstreamURL, {
signal: controller.signal,
});
return await handleResponse(response);
} finally {
clearTimeout(timer);
}这里计时器覆盖处理阶段，但要确认 handleResponse 是否继续读取完整正文，以及是否把取消传到后续请求。只在收到响应头后清除超时，可能让正文下载无限等待。运行时也有自己的限制，应用超时应在平台终止之前提供可理解错误。
多个调用可以共享整体信号，独立调用再设更短预算。并行调用降低串行等待，却增加上游并发和资源使用；只有相互独立的任务适合并行，不应为了速度打乱业务依赖。
取消信号需要跨越完整处理阶段
fetch 返回响应头不等于正文已读完。如果之后等待 JSON 解析，取消信号和期限仍应覆盖读取阶段；若把 body 交给客户端流，则需要另一个清楚的流生命周期策略。不要在获取头后立即清理定时器，却在慢正文上无限等待。对于不支持取消的计算或库调用，AbortController 不会自动终止代码，需要检查取消或采用可中断边界。
多个并行请求可以共享整体信号，同时各自有子期限。组合信号时使用运行时支持的标准能力或成熟封装，保留取消原因并清理监听，避免请求结束后留下大量回调。平台是否支持某个 AbortSignal 方法应根据锁定运行时核对，不为了示例简洁使用未验证能力。计时器、连接和读取器都需要在成功失败后释放。
并行策略适合相互独立的读取，不能让依赖结果提前执行。三个并行上游减少墙钟等待，却增加瞬时并发和费用，可能触发上游限流。对一个热点接口，限制并发或缓存公开结果可能比缩短每个请求期限更有效。预算与资源控制共同设计，避免把局部速度优化变成全局过载。
重试必须花同一个预算
第一次等待结束后再完整重试多次，会把总时长放大。重试前计算剩余时间，采用有限次数与退避，并区分暂时网络故障、上游限流和不可重试业务错误。
GET 通常更适合安全重试，POST 可能产生重复写入。若业务支持幂等键，应由上游定义其语义与有效期，不是客户端随便添加一个头就能保证。对超时写操作尤其谨慎：客户端不知道操作是否已经成功，盲重试可能重复扣费或创建记录。
第一次网络失败后，剩余预算必须同时容纳退避和下一次尝试。重试前判断是否值得开始，若只剩极短时间就直接返回受控错误。有限指数退避加抖动可以减少同步重试峰值，但不是所有错误都可重试。认证失败、输入非法和确定业务拒绝通常需要修复，而不是更长等待。限流时依据协议与剩余期限处理，不能无条件睡完整个 Retry-After。
GET 也不保证服务端实现没有副作用，HTTP 语义应由接口契约遵守。写请求超时尤其有歧义：服务端可能完成了交易，响应只是未到达。支持幂等的上游应使用稳定操作标识和相同有效载荷，重复请求得到同一业务结果。客户端每次重试生成新键，就失去去重意义；上游不支持幂等时应查询状态或让用户明确处理。
重试次数和原因记录成指标，不把全部异常堆栈当作分类。观察重试后成功比例与额外负载，如果大多数重试仍失败，它们可能只在扩大故障。熔断或降级需要自己的恢复条件，不能永久阻断已恢复上游，也不能每个请求都重新试探。复杂机制应由实际故障模式证明必要。
通用 HTTP 客户端、业务服务和入口 handler 都可能设置超时。若它们分别重试，三层重试次数相乘，实际请求数远超表面配置。明确哪一层拥有重试，哪一层只传播取消，避免多个库默默重新开始任务。第三方 SDK 的默认超时与重试需要检查，不能因为业务代码只有一次 fetch 就推断总调用一次。
测试使用记录尝试次数的上游，统计每个整体任务发出多少请求、何时取消。取消后仍收到延迟请求，说明某个包装层没有遵守信号或在后台重试。为必要与可选调用分别记录耗时与取消原因，才能调整真正瓶颈。把总预算继续增大可能让用户等待更久，却没有提高成功率。
降级结果与缓存还需要避免永久遮蔽故障。每次成功返回旧值时记录退化比例与年龄，超过条件报警；恢复后确认读取重新来自新数据。未经过业务批准的陈旧结果不应自动出现，尤其权限与交易状态。预算设计最后应能够回答任务为什么结束、资源是否停止、返回数据有多新，而不是只证明计时器触发过。
取消不是把错误吞掉
AbortError 或超时应进入分类统计，与 DNS 失败、上游 500、解析失败分开。公开响应不需要展示内部堆栈，但应提供稳定状态和关联 ID。不要 catch 后返回空结果，让超时看起来像“没有数据”。
用户断开连接时，应尽量停止不必要工作。某些必须完成的后台步骤可以通过平台机制继续执行，但这应是明确业务决定，不能让每个失败请求都留下无限后台任务。
用户离开页面后，普通读取可以停止；已经被接受的业务写入可能需要完成并保存结果，以便后来查询。不能在浏览器断开后随意中止支付数据库事务，也不能让每个读请求继续执行昂贵上游。根据操作阶段定义取消含义，区分取消等待与撤销业务，两者不总是相同。
公开响应可以给出超时类别与关联 ID，内部日志记录哪个阶段耗尽预算。若用户主动取消，不一定需要计入服务可用性错误；若服务持续超时则需要警报。取消原因有助于解释延迟分布，不能把已经取消的任务误记为正常完成。日志不含用户完整请求体，测量阶段与时间已经足够定位大多数问题。
计时测试使用受控慢上游，允许合理调度误差，不断言恰好某一毫秒。检查总时长在约定界内、没有额外重试、定时器释放。对无法取消的下游，还要观察超时响应之后是否继续耗费资源。用户已经收到错误而后台工作仍长期积压，是预算实现未达到资源目标的证据。
通过一张时间账本检查预算是否真的共享
假设总任务预算中已经消耗索引等待，剩余部分需要容纳摘要、结果序列化与返回。时间账本记录每阶段开始、结束、剩余预算和结束原因。子请求获得的是当前可分配期限，不是原始总时长。并行可选任务也受同一整体截止约束，先完成的任务不能为其他任务重新打开一个完整窗口。数字仅用来解释账本，不作为通用推荐。
计时应在适合持续时间的单调时钟上完成，事件日志再记录墙上时间。服务间传递绝对期限时，需要认识时钟偏差与可信输入；接收方不能允许任意客户端给出更远截止扩张资源上限。明确本地系统最大值与调用方剩余值如何取较短者。期限是一项合作契约，不是客户端可自由申请的无限执行时间。
序列化与解析也占用预算。fetch 已返回头以后，慢正文、超大 JSON 和同步计算可能继续耗时。给正文设置大小限制，检查计算库是否支持中断；不支持时，AbortController 只表达信号而不会抢占同步代码。报告取消请求与实际工作结束的时间，区分“用户不再等”和“资源不再使用”。
重试层数的乘法怎样放大故障
入口允许三次尝试，业务库每次又重试三次，SDK 再重试三次，最坏调用次数不是九次而可能继续相乘。示例不是说所有库采用三次，而是提醒总调用图必须审查。为每个操作指定唯一重试所有者，其他层传播错误或明确关闭默认重试。仍需保留整体期限，防止一次允许尝试持续超出任务预算。
上游在故障期间收到同步重试，会增加排队并让更多请求超时。有限退避与抖动减少同步，但不能创造容量。观察重试后的成功比例、额外请求量与期限耗尽位置，再判断是否值得重试。认证错误与确定非法输入直接失败，限流根据受支持的 Retry-After 与剩余期限处理，不在只有少量余量时继续等待很长时间。
测试上游计数尝试并可控制每次结果，断言一个整体任务最多发出批准次数，且退避包含在总期限。取消后不应启动延迟重试。若 SDK 无法接受信号，至少了解其工作是否仍继续，并限制其并发和寿命；不能只在外层 Promise.race 返回超时就宣称下游已结束。Promise 不再被等待与任务停止不是一回事。
可选步骤失败如何保持输出可辨识
搜索标题与链接已具备，摘要补充失败时可以返回不含摘要的合法结构。可选字段在类型中明确，模板不把缺失理解为正文空白或未找到文章。若使用旧摘要，保留出处时间和退化标识，产品按需求表达。读取公开信息允许的陈旧范围，不能直接应用到权限、价格或交易状态。
并行可选步骤一旦超过自身期限，可以停止其工作并继续生成必要结果；整体必要步骤失败则停止其他不再需要的读取。allSettled 可以收集结果，但若一直等待所有不可取消任务，仍可能超出用户预算。选择聚合机制依据依赖与取消能力，不把一个 Promise 方法名当作完整可靠性方案。
退化持续发生时独立报警，因为前台二百可能掩盖长期上游失败。恢复测试确认新数据重新出现，并且旧退化标记不会永久保留在缓存。业务批准的降级与错误吞没不同，前者有类型、来源、期限和观测，后者只提供一个看起来成功的空对象。
写入超时需要查询而非猜测结果
用户提交创建任务，上游超时以后可能已经提交。客户端保留操作标识并查询状态，若上游支持幂等则重复同一请求使用同一标识与有效载荷。每次重试生成新键会变成新的操作。上游不支持可靠结果查询时，界面说明结果未知并给出受控处理路径，不承诺“未执行，可以放心再点”。
客户端断开连接，也不应随意取消已经接受的关键业务提交。服务端根据操作阶段决定继续完成并记录结果，后续用户可以查询。普通搜索读取则通常可以停止。用户等待取消、网络传输取消与业务撤销分别建模，按钮文案和接口契约反映真实能力，不将 AbortSignal 误描述为撤回所有副作用。
测试响应头迅速到达但正文持续缓慢的端点，可以发现计时器过早释放。再用返回巨大合法 JSON 的端点检查解析阶段是否受大小预算保护，应用超时信号不一定能抢占同步解析。解决方案可能是降低允许体积、采用流式协议或将计算移入可中断任务，而不是给 fetch 加更短常量。
还要验证异常清理不会覆盖原始原因。finally 中清理连接或记录日志也可能失败，若新异常取代最初的超时，观测会误分类。清理采用受控错误路径，保留主要失败事实并记录必要次要类别，不能为了让响应顺利返回将所有错误一律忽略。期限实现的可解释性也包含这些尾部阶段。
流式响应要区分空闲期限与总期限
上游每隔一段时间发送一个很小的数据块，空闲计时器不断被重置，整个下载却可以持续很久。空闲期限限制两次可用进展之间的间隔，总期限限制一次任务占用资源的累计时间，两者不能互相替代。还需限制总字节数，避免靠持续小块绕过一次性正文大小检查。
受控夹具分别模拟长时间无数据、持续小块和快速超大数据，核对触发的是哪项限制。已经把部分流发给客户端以后，不能再假装返回一份全新的正常 JSON 错误；协议要定义流中断怎样表示未完成，消费者不得把残缺内容当作完整结果。这里讨论验收设计，不宣称所有 fetch 包装器都提供这组限制。
故障实验检查尾部工作而不只看响应时间
让上游慢头、慢正文、成功后断开和限流，测量总响应与取消后仍持续的调用。期限附近允许运行时调度误差，不断言精确某毫秒；断言没有新的尝试、定时器和监听被清理、资源回到可接受状态。对照无重试与有限重试，报告任务成功、延迟和额外负载，不能只挑平均响应变快的一项。
整体预算的工程价值是等待可预测且资源受控。外部系统仍然不确定，退化与未知结果仍然存在；一张准确时间账本与完整恢复契约，比不断调整三个局部常量更能解释任务为何结束。
等待执行槽位也要消耗同一预算
接口把请求送进并发限制器，排队两秒以后才开始 fetch。如果超时从取得槽位时重新计时，繁忙时用户等待会超过表面预算，空闲测试却全部正常。任务开始时确定整体期限，队列等待、连接取得和网络调用共同消耗它；获得槽位后重新计算剩余时间，没有余量就不再发出上游请求。
等待队列需要可移除的取消项。用户已经离开，排队任务仍在未来取得槽位并执行，会把负载控制变成延迟产生无用工作。用受控执行器占住唯一测试槽位，加入第二个任务并取消，再释放槽位；上游计数应不增加，等待状态与监听应被清理。这个样本验证的是准入阶段，不是正常 fetch 的取消。
排队上限与执行上限也分别定义。无限积压虽降低同时调用量，却增加内存、等待和过期任务。超过批准队列容量时返回可理解的繁忙结果，不在多个层再排一次队。指标区分排队拒绝、排队期限耗尽和实际调用超时，才能知道应该调整并发、容量还是上游预算。这里没有测量真实吞吐，阈值仍需由目标系统实验确定。