AbortController实现去重与熔断方案

本文深入探讨了如何基于原生 AbortController 构建一个兼具请求去重与熔断能力的前端网关方案，指出其原生能力仅限于中止信号，必须通过封装实现指纹标准化（涵盖 URL、method、规范化 body 和关键 headers）、Map 缓存管理、滑动时间窗口失败统计及跨请求共享的熔断状态；强调去重需精准归一化请求特征（如排序 query、标准化 JSON 键序、排除动态 token 头），熔断须独立维护持久化开关并支持 half-open 探测机制，同时警示 signal 传递、abort 主动触发、缓存清理和生命周期解耦等易错细节——为高可靠、高性能前端网络层提供了可落地的工程化实践指南。

AbortController 本身不支持去重和熔断，得自己封装

AbortController 只提供中止信号（signal），没有请求指纹识别、缓存判定或失败计数能力。想实现去重和熔断，必须在它之上加一层控制逻辑——比如用 Map 缓存正在进行的请求，用 WeakMap 关联 signal 与状态，再配合时间窗口计数器。直接把 fetch 包一层 AbortController 是没用的。

请求去重的关键是标准化请求指纹

去重不是看 URL 一样就跳过，而是要对整个请求可变因素做归一化处理：URL + method + JSON.stringify(body) + headers 中参与鉴权/过滤的字段（如 X-Region）。否则带不同 token 或分页参数的请求会被误判为重复。

• GET 请求用 URLSearchParams 对 query 排序后拼接，避免参数顺序不同导致哈希不一致
• POST/PUT 的 body 必须先 JSON.stringify 再 JSON.parse 标准化键序（或用 canonicalize 库）
• 不要把 Authorization 头纳入指纹——token 刷新时会频繁误击去重
• 去重只对「相同指纹且 signal 未 abort」的请求生效；若前一个已 abort，新请求应正常发起

熔断需独立于单次请求生命周期维护状态

熔断开关（circuit breaker）必须跨请求共享，不能每次 new 一个 AbortController 就重置。典型做法是用闭包或模块级变量维护一个 Map：key 是请求指纹，value 是 { failureCount, lastFailureTime, isOpen }。触发熔断后，后续同指纹请求直接 reject，不再发网络调用。

• 建议使用滑动时间窗口（如最近 60 秒内失败 ≥ 5 次）而非固定周期，避免边界抖动
• 熔断开启后，可设一个 halfOpen 状态：等待一段时间后放行一次试探请求，成功则关闭熔断，失败则重置计时器
• 注意清理过期条目，否则 Map 持续增长；可用 setTimeout 配合 delete，或用 LRU cache 库
• AbortSignal 的 aborted 属性只反映是否被主动中止，不能用来判断熔断 —— 熔断应抛出明确错误，如 new Error('CIRCUIT_OPEN')

组合使用时 signal 的传递与监听容易漏掉

封装网关函数时，常犯的错是只把 signal 传给 fetch，却忘了在去重命中或熔断触发时手动调用 abort()，导致上层无法感知中止。正确做法是：只要不真正发请求，就要创建新的 AbortController 并立即 abort()，然后把它的 signal 返回出去。

• 去重命中时：从缓存取原 promise，同时 const ac = new AbortController(); ac.abort(); return { promise, signal: ac.signal }
• 熔断开启时：同样新建 AbortController 并 abort，再 throw 错误（错误需包含 name: 'CircuitBreakerOpenError' 方便上层捕获）
• 务必在返回的 promise finally 中清理缓存项，否则内存泄漏；但清理时机要区分：是正常 resolve、reject 还是 signal abort
• 别在 signal.addEventListener('abort', ...) 里做异步操作——事件可能在 promise 已 settle 后才触发

本篇关于《AbortController实现去重与熔断方案》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！