AbortController仅提供中止信号，不支持去重和熔断；需在其上封装请求指纹标准化（URL+method+body+关键headers）、Map缓存、滑动窗口失败计数及跨请求共享的熔断状态管理。
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，不再发网络调用。
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
- 建议使用滑动时间窗口（如最近 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 后才触发
