AbortController实现请求去重与熔断方案

本文深入剖析了如何基于 AbortController 构建健壮的前端网关能力——通过在外层封装逻辑层，利用 Map 实现精准请求去重（需标准化方法、URL、body 和关键 headers 生成唯一 key），并结合独立的状态管理实现熔断控制（为每个接口路径共享熔断器实例，基于时间窗口和失败阈值动态切换状态）；同时强调了 abort 与熔断的职责边界、清理时机及常见陷阱，尤其指出「去重 key 的语义一致性」和「熔断器实例生命周期」是落地成败的关键，稍有疏忽就会导致功能失效或内存泄漏，值得每一位追求高可用前端架构的开发者重点关注。

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

AbortController 只负责中断请求，它既不会记住你发过什么请求，也不会统计失败次数。想实现去重和熔断，必须在它外面包一层逻辑层——比如用 Map 缓存 pending 请求，用计数器 + 时间窗口做熔断判断。直接往 fetch 或 axios 里塞一个 AbortController 实例，什么都解决不了。

请求去重的关键是标准化请求标识

去重不是看 URL 一模一样就行，得考虑参数序列化方式、请求方法、body 内容（尤其 POST）、headers 中影响结果的字段（如 Accept）。常见错误是只比对 url，结果 GET /api/user?id=123 和 GET /api/user?id=123&lang=zh 被当成同一个请求。

• 推荐用 URL 构造函数 + URLSearchParams 规范化查询参数顺序
• POST/PUT 的 body 若为对象，需用 JSON.stringify 且保持 key 排序（可用 JSON.stringify(obj, Object.keys(obj).sort())）
• 把方法、标准化后的 URL、body hash、关键 headers 拼成唯一 key，例如：GET#https://a.com/u#{"id":1}#accept:json
• 用 Map 存 pending 的 Promise 和对应的 AbortController，后续相同 key 的请求直接复用返回值

熔断需要独立的状态管理，不能依赖单次 AbortController

熔断是跨请求的策略，要记录某接口最近 N 秒内失败次数、是否处于 open 状态、下次半开时间等。AbortController 的 abort() 只是中断当前请求，对熔断状态毫无感知。

• 为每个接口路径维护一个熔断器实例（比如用 new CircuitBreaker({ timeout: 60_000, failureThreshold: 3 })）
• 每次请求前调用 circuitBreaker.canRequest()，返回 false 就直接 reject，不发请求
• 请求失败后调用 circuitBreaker.recordFailure()，成功则 recordSuccess()
• 注意：熔断器必须共享，否则多个组件各自 new 一个就失效了；建议用 Map 按 path 存，或全局单例 + 路径分片
• 别把熔断逻辑写进 signal.addEventListener('abort', ...) —— 那只是响应中断，不是响应失败

组合使用时注意 abort 与熔断的优先级和清理时机

一个请求可能同时被 abort 和熔断拦截，但它们触发时机和目的不同：abort 是用户主动取消（比如跳页），熔断是系统保护（比如服务端持续 503）。如果不清除已缓存的 abort 控制器，会导致后续相同请求被意外中止。

• 去重 Map 中的 value 应该是 { promise, controller, cleanup }，其中 cleanup 在 promise settle 后移除自身
• 熔断器 open 时，仍要检查是否有 pending 请求——如果有，应主动 controller.abort() 并从 Map 中删除，避免内存泄漏
• 不要在 finally 块里统一 abort：有些请求根本没走到 fetch 阶段（比如被熔断拦截），controller 根本没传进去
• 调试时留意控制台是否出现 AbortError: The user aborted a request. —— 如果高频出现且非用户操作引起，大概率是 abort 控制器复用或未清理导致

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《AbortController实现请求去重与熔断方案》文章吧，也可关注golang学习网公众号了解相关技术文章。