abortcontroller 主动中止旧请求以避免竞态，关键在于生成语义一致的请求 key（排序参数、过滤敏感字段），配合 map 管理 controller 并在 finally 清理，支持实例化隔离与手动干预，react 中需在请求前即时 abort 而非仅依赖卸载清理。

这不是“合并请求”，而是用 AbortController 主动干掉旧请求——新请求一发，旧的立刻 abort，避免竞态和资源浪费。

如何生成稳定、可比对的请求 key

key 不等于 URL，它必须包含所有影响响应结果的参数。比如 GET /users?sort=name&limit=20 和 GET /users?limit=20&sort=name 是同一个请求，但原始字符串不等价。

• GET 请求：用 URLSearchParams 构造后调用 .toString()，前提是先对键名排序（Object.keys(params).sort()）
• POST/PUT 请求：若需按 body 聚合，用 JSON.stringify(body, Object.keys(body).sort())，但要过滤掉敏感字段（如 token、csrf）
• headers 中参与聚合的字段（如 Accept-Language）需显式声明，不能全量取
• 推荐封装成 getRequestKey(method, url, options)，统一处理 undefined、数组顺序、空对象等边界

为什么 Map + abort() 组合必须配 finally 清理

不清理就会内存泄漏——每个未完成的请求都持有一个 AbortController 实例，而它的 signal 会一直保留在 Map 里，哪怕请求已失败或被 abort。

• 每次请求前：计算 key → 若 abortMap.has(key)，先调 abortMap.get(key).abort()
• 新建 controller = new AbortController()，存入 abortMap.set(key, controller)
• fetch 后必须在 .then().catch().finally() 或 try/catch/finally 块中执行 abortMap.delete(key)
• 注意：controller.abort() 多次调用无副作用，但 abortMap.delete(key) 必须确保只执行一次

封装 fetchAggregated 时怎么支持手动干预和多实例隔离

单例 Map 看似省事，但在微前端或多 tab 场景下容易跨域污染；而完全不共享又失去聚合意义。折中方案是提供实例化能力，并暴露控制接口。

• 默认导出单例函数 fetchAggregated(url, options)，内部用私有 Map
• 同时导出工厂函数 createAggregatedClient()，返回带独立 Map 和 abortByKey(key) 方法的对象
• options.aggregate = false 可临时绕过聚合逻辑，方便调试竞态问题
• 不要在 catch 中吞掉 AbortError，应保留原错误类型或打上标记（如 error.isAborted = true），便于上层区分失败原因

React 中 useRequest 怎么安全绑定 abort 生命周期

不能只靠组件卸载时 useEffect 清理——用户快速输入搜索词时，前一个请求还没结束，新请求已触发，此时旧请求必须被 abort，而不是等组件卸载才处理。

• 用 useRef 存当前 AbortController，每次请求前先 current?.abort()
• 不要在 useEffect 里直接发起请求，而应在事件回调（如 onInput）中调用请求函数
• 如果配合防抖，abort 应发生在防抖定时器重置时，而非防抖结束后——否则仍会残留“幽灵请求”
• 注意：signal 是只读属性，不可重新赋值；controller.signal 每次都要新创建，不能复用

真正难的不是写 abort() 这一行，而是 key 的语义一致性——只要两个请求的 key 相同，它们就必须返回相同结果，否则聚合就变成 bug 来源。这个前提一旦松动，整个架构就从优化变成陷阱。

大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！