超级管理员
楼主
一篇文章引发了关注：ffetch 的作者测试了多款 fetch 封装库（Ky、ofetch、Wretch 等），考察它们如何处理重试、超时与取消逻辑，以及这些策略在哪些场景下会出现冲突。
问题背景
现代 HTTP 客户端除了发请求，还要处理：失败了要不要重试、多久算超时、用户取消了怎么办。这三个策略单独看都有最佳实践，组合起来却经常出问题。
典型的冲突场景
重试和超时打架：每个请求单独设超时 5 秒，重试 3 次，总耗时可能到 15 秒以上——而调用方以为自己设了 5 秒。总预算（overall budget）和单次超时（per-attempt timeout）是两个概念，多数库默认只给了后者。
取消与重试打架：请求被取消后，重试逻辑是否还继续？如果继续，取消就形同虚设；如果不继续，中间态谁来清理。
指数退避的细节
退避算 jitter 吗？重试上限按次数还是按总时长？429 和 503 的 Retry-After 头被尊重了吗？5xx 重试还是所有错误都重试？这些细节决定了库在高并发下的实际行为。
实操建议
第一，明确区分单次超时与总预算，两者都要设。第二，只对幂等方法或者明确安全的重试场景自动重试。第三，取消信号要能穿透重试循环。第四，服务端返回 Retry-After 时优先遵循。
选库的判断标准
不要看 star 数，看这三者的组合语义是否清晰、是否可配。文档里如果没写清楚默认的组合行为，这个库大概率有坑。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。