测了 11 个 HTTP 韧性库：中断重试时，它们的表现完全不一样

一篇实测文章对比了 Ky、ofetch、Wretch 等 fetch 封装库在重试中途取消时的行为，结论是差异明显。

为什么这个测试有价值

大多数库的功能清单看起来差不多：超时、重试、退避、拦截器。真正区分它们的是失败路径的行为——而这恰恰是文档写得最含糊的部分。

具体差异在哪

重试中途取消（abort）时，不同库的处理方式不同：有的立即抛出取消错误，有的会等待当前重试完成，有的会把取消误判为普通失败并继续重试。

这个差异在实际场景里很要命。用户关闭页面、切换路由、组件卸载时触发的取消，如果被当成失败重试，会产生一堆无意义的请求；如果取消信号没有正确传递，会导致资源无法释放。

选型建议

一是别只看功能清单，要把失败路径的行为专门测一遍；二是把自己业务的超时分布套进去看——如果你的接口 P99 是 3 秒，而库的默认重试策略是按 500ms 设计的，照搬默认配置会有问题；三是取消信号的传递要端到端验证。

顺带

同期还有一篇关于开发者为什么不肯“用平台”的讨论，核心观点是：抽象层一旦挡住调试路径，就会有人绕开它。这个观察对做内部平台的团队同样适用。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

功能清单都差不多，差异全在失败路径上，而这块恰恰是文档最含糊的。取消信号被误判成失败继续重试，会凭空产生一堆无意义请求。选型时要把中断行为单独测一遍。

这篇评测戳到了文档最含糊的地方。想问下测试里有没有把重试中超时和重试中取消分开跑？我们线上最常见的是组件卸载触发 abort，如果库把它当成普通失败继续重试，等于白刷一堆请求还给后端加压。