1. 到底什么是“ax调度”从一句玩笑到核心工程问题1.1 “ax调度”这个热词戳中的是每个前端都绕不开的痛点最近技术社区里有个热词叫“ax调度”被不少同事拿来调侃说是资深前端每天的日常就是面红耳赤地跟 ajax 请求搏斗——怎么排队、怎么取消、怎么重试、怎么不把后端打挂。话是玩笑但说得非常实在。如今的前端项目尤其是中后台管理系统和重交互的 C 端应用本质上就是在做一件事把一堆异步事件编排成一个稳定、不跳变、不闪烁的 UI 状态。而“ax”这个缩写在多数人语境里指向 Ajax/Axios 这类异步请求“调度”则是对这些请求的全过程管理。我用一个后厨的例子来解释“调度”到底在调度什么。客人点菜是异步的后厨炒菜也是异步的但出菜口必须有个明确的规则哪一桌的菜先上、哪道菜先做、点菜量太大时怎么排队、某道菜做坏了要重做几次。如果出菜口没有规则高并发下必然会乱套——有的菜凉了有的菜重复上有的客人催了三遍还在等。前端请求调度面对的是同样的局面搜索框每敲一个字就发一次请求多个接口之间存在依赖关系页面切换时旧请求还没返回批量上传时几十个请求同时发出去任何一个环节没有规则用户感知到的就是数据错乱、页面卡顿、按钮一直转圈。所以我一直觉得“ax调度”不是新造的概念而是把以前揉在业务代码里、散落在各个组件里的异步请求管理问题单独拎出来给了个名字。它解决的是“在资源有限、网络不确定、用户操作随机的环境下请求仍然能以正确顺序、合理时效、可控数量完成”的问题。这篇文章的价值在于帮你把这个问题彻底理清适合被请求竞态折腾过的新人也适合想把异步逻辑从组件中剥离出来的老手。1.2 不是只有大项目才需要五个最典型的业务场景有人觉得调度是架构师才考虑的事业务页面不就是发个请求、拿到数据渲染吗真不是。我随手就能列出五个每个前端都写过的场景每一个都在做调度。第一个是搜索联想。用户输入“苹果”可能先触发了一次“苹”再触发一次“苹果”。网络环境下后发的请求可能先返回也可能先发的请求后返回。如果不对响应做处理页面上很可能会出现输入“苹果”却显示“苹”的联想结果。第二个是级联筛选比如先选省份再选城市城市列表依赖省份。如果不做时序控制用户快速切换省份时上一次的请求结果没有及时清掉新旧数据互相覆盖。第三个是批量上传一次选 30 个文件如果 30 个请求同时发出浏览器连接数被占满上传进度和失败重试都不可控。第四个是列表分页用户快速翻页时上一页的请求突然返回把当前页数据覆盖成旧数据表格里出现“灵魂闪现”。第五个是登录后的初始化流程拿 token、拉用户信息、拉权限列表、拉菜单配置彼此之间有先后依赖任何一个失败都会导致后续全部白拉。这些场景单独看都不难但合在一起它们暴露的是同一个本质请求不能只发不管必须有统一的机制来约束“什么时候发”“发几个”“怎么处理过期响应”“失败后怎么办”。这就是调度的核心价值也是为什么“ax调度”能成为一个值得讨论的话题——它看起来不高级但实际项目里八十的线上问题都出在这一层。2. 请求调度要解决的四个基本问题2.1 竞态裁决当响应顺序和发起顺序不一致竞态是异步编程里最常见的坑也是“ax调度”里最优先要解决的问题。网络请求没有保证返回顺序你在时间点 T1 发起请求 A在 T2 发起请求 B但 B 可能比 A 先返回。如果不做处理页面最终显示的是 A 的结果而这个结果早已不是用户最新操作对应的数据。解决竞态最直接的两个思路一个是“取消”一个是“丢弃”。取消的思路是一旦新请求发出就把旧请求真正中止掉。浏览器原生提供一个非常好用的 API叫 AbortController。它的用法很简单const controller new AbortController(); fetch(/api/search?q苹果, { signal: controller.signal }); // 用户继续输入旧请求不再需要 controller.abort();fetch 会监听 signal 上的中断通知中断后本次请求直接失败不会再产生响应。如果用 axios同样支持 signal 参数底层逻辑一致。在实际项目里我一般会封装一个带取消能力的请求函数把 controller 的创建和中止都收敛在一个地方避免每个页面都重复写一遍。function createCancellableRequestT( url: string, options?: RequestInit ) { const controller new AbortController(); return { signal: controller.signal, abort: () controller.abort(), run: async (): PromiseT { const res await fetch(url, { ...options, signal: controller.signal }); return res.json() as PromiseT; } }; }但有时候你不想真正取消因为旧请求的结果可能还有缓存价值比如搜索联想里的热门词结果。这时用“丢弃”策略更合适给每一次请求加一个自增序号响应返回后对比序号如果已经过期就直接忽略。let seq 0; async function search(keyword: string) { const current seq; const res await fetch(/api/search?q${keyword}).then(r r.json()); // 如果期间又发起了新请求当前响应直接丢弃 if (current ! seq) return; renderResult(res); }这个方案虽然简单但工程上非常可靠。我见过很多团队没有做任何竞态保护线上用户反馈“搜索不准确”“筛选乱了”排查到最后都是同一个原因。竞态裁决的核心原则其实就是一句话让用户最新的一次操作决定界面状态其余结果只能让路。2.2 并发控制浏览器和后端都受不了一次全发并发控制说起来也简单不限制当前同时执行的请求数量。为什么必须限制两个原因。第一个是浏览器自身的物理限制。HTTP/1.1 下同一个域名最多只能建立大约 6 个 TCP 连接超出部分会排队等待。如果一个页面同时发 20 个请求后 14 个必须等前面的完成用户直观感受到的就是接口迟迟不返回。第二个原因是服务端压力。哪怕页面和接口都走 HTTP/2多路复用让单域名连接数不再紧张但后端应用服务器依然有线程池、连接池、数据库连接数上限。一次页面操作触发 30 个查询请求数据库可能直接打满整个系统都跟着变慢。所以“并发数”必须显式控制。这里有一个经典的并发池思路核心是维护一个待执行队列和一个“正在执行数量”的计数器。当计数器低于上限时从队列头部取出任务执行每当一个任务完成计数器减一再自动取出下一个任务。async function runWithConcurrencyT( tasks: Array() PromiseT, limit: number ): PromiseT[] { const results: T[] new Array(tasks.length); let index 0; async function worker() { while (index tasks.length) { const current index; results[current] await tasks[current](); } } const workers Array.from( { length: Math.min(limit, tasks.length) }, () worker() ); await Promise.all(workers); return results; }worker 的数量就是并发上限每个 worker 不断从任务数组里取下一个任务取完为止。这个模式的优点在于并不是把 30 个请求同时丢出去而是始终保持最多 N 个在执行。对上传文件、批量初始化这类场景效果立竿见影。具体并发数设多少不要拍脑袋。我一般先看接口耗时和机器配置再从浏览器 Network 面板观察 queueing 阶段的长短。常见项目里 4 到 6 并发是相对稳妥的值既不浪费网络带宽也不会让服务端难堪。注意这个“4 到 6”是经验值不是标准答案最好根据实际并发测试调整。2.3 时序编排接口之间的依赖关系不能靠运气竞态管的是“乱序”并发管的是“数量”时序编排解决的是“依赖”。不少业务接口天生有先后关系先拿登录凭证再拿用户信息最后拿权限列表。这个顺序如果乱了页面轻则报错重则泄露不属于当前用户的菜单和数据。最简单的串行方式就是 await 一个一个等代码很好看但效率偏低。稍微进阶一点的做法是把“并行无关”和“串行依赖”拆开没有依赖关系的接口用 Promise.all 一起发有依赖关系的接口用 await 显式等待前一步完成。const token await fetch(/api/token).then(r r.json()); // 这两个接口互不依赖可以并行 const [userInfo, permissions] await Promise.all([ fetch(/api/user, { headers: { Authorization: Bearer ${token} } }).then(r r.json()), fetch(/api/permissions, { headers: { Authorization: Bearer ${token} } }).then(r r.json()) ]); const menus await fetch(/api/menus?role${permissions.role}).then(r r.json());这里要强调一个容易踩的认知误区很多人喜欢用 Promise.all 处理全部请求觉得“并发”就是快。但 Promise.all 有一个特性任何一个请求失败整体立即 reject其他请求的结果全部丢弃。如果你的场景是“能拿到多少算多少”比如页面首屏由三个独立模块组成其中一个接口挂了其余模块仍然应该显示那就应该用 Promise.allSettled 而不是 Promise.all。还有一点是关于“自动化的依赖编排”。有的项目会引入 DAG 依赖图之类的重型机制去自动分析接口依赖我的实际体会是除非你的接口由可视化编排系统生成否则业务代码里显式写清依赖关系远比自动化推断可靠。因为接口依赖往往夹带着业务状态比如“必须先选中一条记录才能查详情”这类逻辑不在接口参数层面自动化编排根本感知不到强行抽象只会增加复杂度最后还是要手写时序逻辑。2.4 重试与降级调度里最容易玩火的部分重试机制是调度的最后一道防线也是最容易写错的地方。不少人的第一版重试代码是“失败就再来一次”看起来直接但线上常常会因此吃大亏。设想一个场景后端接口因为依赖的数据库连接池打满导致大量请求 5 秒超时如果每个请求失败后立刻重试 3 次原本 100 个请求进来实际打到后端的可能是 400 个后端被进一步压垮形成“重试风暴”。正确做法是对每一次重试做退避也就是让重试间隔随次数指数增长。指数退避的常见公式是延迟时间 基础延迟 × 2 的 n 次方再加上一个随机抖动避免多个请求在同一时刻集体重试。function getBackoffDelay(baseMs: number, attempt: number): number { const exponential baseMs * 2 ** attempt; const jitter Math.random() * 100; return exponential jitter; } // 第 0 次失败后等待约 500ms // 第 1 次失败后等待约 1000ms // 第 2 次失败后等待约 2000ms除了退避还有一个容易忽略的原则不是所有失败都适合重试。HTTP 4xx 这类客户端错误比如参数不对、鉴权失败重试多少次结果都一样反而浪费服务端资源。真正值得重试的是网络层错误和 5xx 服务端错误因为前者可能是临时断网后者可能是短暂的负载高峰。在 fetch 中网络错误通常表现为 TypeError: Failed to fetch判断起来并不难。重试之外还要考虑降级。不是所有请求失败都必须失败到底合理的降级策略能大幅改善用户体验列表接口失败可以展示缓存数据并提示“数据可能不是最新”详情接口失败可以展示骨架屏加一张空状态图权限接口失败可以默认收起所有敏感操作。降级的本质是“在有损状态下仍然给出可用的界面”而不是一直转圈直到用户刷新页面。如果你发现某个接口在持续失败还应该考虑更底层一点的“熔断”思路记录连续失败次数达到阈值后短时间内直接拒绝新的请求不再打到后端等冷却窗口过去再恢复。熔断的细节这里不展开但记住一个结论就够了调度器不仅要管“怎么发请求”更要管“发了之后失败到什么程度必须停手”。3. 自己动手写一个轻量“ax调度器”3.1 先想清楚调度器对外长什么样把上面的机制整合成一个能用的调度器并不需要写出一个复杂的框架。我建议从对外接口开始设计一个调度器至少满足四个诉求并发上限、任务优先级、失败重试、外部取消。我设计的一个最小接口是这样export interface SchedulerTaskT unknown { id: string; priority?: number; // 越大越优先 executor: (signal: AbortSignal) PromiseT; timeout?: number; // 单次执行超时 retries?: number; // 最大重试次数不含首次 baseDelay?: number; // 指数退避的基础延迟 } export interface AxScheduler { addT(task: SchedulerTaskT): PromiseT; cancel(taskId: string): boolean; }调用方使用起来非常直观const scheduler new AxScheduler({ concurrency: 4 }); const result await scheduler.add({ id: user:list, priority: 10, executor: signal fetchUsers(signal), timeout: 5000, retries: 2, baseDelay: 300, });为什么把优先级设计成数字而不是字符串因为数字天然可比较、可排序而字符串最终还要映射成数字才能参与排序。优先级的含义是“当并发池已满时高优先级的任务可以插队先执行”。在业务里这非常有用用户主动点击的操作应当优先于后台的预加载、批量同步等低优先级任务。3.2 优先级队列与并发池的实现调度器内部有两块核心数据结构一个待执行任务队列和一个“当前正在执行的数量”计数器。任务入队后先按优先级排序每次有机会执行时从队列里取出优先级最高的任务开始执行。由于绝大多数场景的任务量不会大到需要引入二叉堆我用数组加线性扫描来挑最大优先级任务代码可读性反而更好。如果你的工程里任务量上万再考虑换成优先队列实现。interface InternalTask { id: string; priority: number; retries: number; baseDelay: number; timeout?: number; executor: (signal: AbortSignal) Promiseunknown; resolve: (value: unknown) void; reject: (reason?: unknown) void; } class AxScheduler { private queue: InternalTask[] []; private activeCount 0; private readonly concurrency: number; constructor(options: { concurrency: number }) { this.concurrency options.concurrency; } addT(task: SchedulerTaskT): PromiseT { return new PromiseT((resolve, reject) { this.queue.push({ id: task.id, priority: task.priority ?? 0, retries: task.retries ?? 0, baseDelay: task.baseDelay ?? 500, timeout: task.timeout, executor: task.executor, resolve: resolve as (value: unknown) void, reject, }); this.next(); }); } cancel(taskId: string): boolean { const index this.queue.findIndex(t t.id taskId); if (index -1) return false; this.queue.splice(index, 1)[0].reject(new Error(task cancelled)); return true; } private next(): void { while (this.activeCount this.concurrency this.queue.length 0) { const bestIndex this.queue.reduce( (best, item, index) item.priority this.queue[best].priority ? index : best, 0 ); const [task] this.queue.splice(bestIndex, 1); this.activeCount; this.execute(task) .then(task.resolve) .catch(task.reject) .finally(() { this.activeCount--; this.next(); }); } } }这段代码里的核心逻辑集中在 next() 方法里。每次有任务完成activeCount 减一然后立刻调用 next() 从队列里补充新任务。因为 while 循环会持续到并发池满或者队列为空所以哪怕同时完成多个任务并发数也不会超限。3.3 竞态取消与超时控制如何接入上面这个版本的调度器还缺两个关键能力单次执行超时以及任务开始后还能被外部取消。超时控制很简单给每个 executor 包一层带 timeout 的 Promise 即可。但注意超时不能只靠 Promise.race 的方式因为真正发出去的 fetch 请求并不会因为外层 Promise 失败而停止必须配合 AbortController 才能把网络请求真正中断。更优雅的方案是让“超时”和“取消”复用同一个 AbortController。统一封一个执行函数private execute(task: InternalTask): Promiseunknown { const controller new AbortController(); let timer: ReturnTypetypeof setTimeout | undefined; if (task.timeout) { timer setTimeout(() controller.abort(), task.timeout); } const promise task.executor(controller.signal) .finally(() { if (timer) clearTimeout(timer); }); // 外部通过 cancel 传入该任务的 signal // 如果 need 取消调用 controller.abort() return promise; }但要支持“按任务 id 取消正在执行的任务”调度器还需要维护一个从 id 到 controller 的映射。我在上一节代码中暂时没有加这个表实际补充很简单在 execute 内部加一个 Map 记录开始时写入结束时删除。如果业务组件在页面卸载时调用 scheduler.cancel(user:list)调度器就会让该任务正在执行的请求直接中断。这样调度器就同时做到了三层取消任务在排队中取消直接从队列移除任务执行中取消中断底层请求任务已取消时重试逻辑自动跳过不再发起新的请求。这三层是竞态保护的地基。3.4 业务里怎么用搜索框和批量导入两个实例有了调度器业务代码可以非常干净。拿搜索联想来举例我只需要在组件里维护一个调度器实例每次输入变化时先把上一次同 id 的任务取消再添加一个新任务。注意在真实项目里调度器应该做成全局单例而不是组件内部 new 一个否则切换组件时正在执行的任务就失去控制了。这里为了展示语义先在组件外创建共享实例。const sharedScheduler new AxScheduler({ concurrency: 6 }); let searchId 0; async function onSearchInput(keyword: string) { const currentId search:${searchId}; sharedScheduler.cancel(search:${searchId - 1}); const data await sharedScheduler.add({ id: currentId, priority: 10, executor: signal fetch(/api/search?q${encodeURIComponent(keyword)}, { signal }) .then(r r.json()), timeout: 3000, }); renderList(data.list); }这个写法最直观的好处是无论用户输入多快上一个请求要么被取消要么返回后被遗弃不会出现“慢请求覆盖快结果”的经典问题。而“搜索联想”这类高频请求占用了并发池时其他页面里的普通请求依然可以正常执行。批量上传场景则更像一个异步任务队列。每次用户选择一批文件就把每个文件封装成单独任务设置较低的优先级限制并发数量。这样不会因为用户一次性选了 20 个文件就把整个浏览器的请求队列占满。const fileScheduler new AxScheduler({ concurrency: 4 }); function uploadFiles(files: File[]) { return Promise.allSettled( files.map((file, index) fileScheduler.add({ id: upload:${Date.now()}:${index}, priority: 5, executor: signal uploadFile(file, signal), timeout: 30000, retries: 2, baseDelay: 1000, }) ) ); }注意这里的返回结果是 Promise.allSettled一个文件失败不会影响其他文件继续上传。调度器内部则通过 timeoute 和 retries 实现了“失败自动重试”用户完全不感知重试过程但上传成功率会明显提升。3.5 调度器设计的取舍与工程边界有一个问题经常被讨论既然已经有 p-limit、p-queue 这些成熟库为什么还要自己写我的观点是生产环境首选成熟库没有任何问题p-queue 甚至原生提供了优先级、并发、超时能力。自己写一遍调度器的价值在于“理解”理解之后你才能判断一个第三方库是否合适、需要怎么配置、出了问题怎么排查。即便最后你用了 p-queue也不影响你对这类问题的认知深度。还要提醒一点调度器只应该管任务的执行机制不要管业务状态。比如“搜索联想结果应该渲染在哪个 div 里”“上传成功后要不要更新列表”这些属于业务层逻辑。如果把业务状态也塞进调度器调度器很快就会变成一个难以维护的“上帝对象”。保持职责单一才能让调度器足够通用、足够稳定。这也是我在实际项目里最深的体会。4. 实际项目中容易踩的五个坑与排查实录4.1 坑一请求是取消了但定时器和内存泄漏没跟着取消先描述一个真实场景页面里有一个轮询接口每 5 秒拉一次最新状态。用户切走页面组件卸载时开发者把轮询定时器清掉了但上一次还没返回的请求没有取消。过了几百毫秒请求返回回调里执行了 setStateReact 在控制台打出那个经典的警告——“对已卸载组件执行状态更新”。更麻烦的是如果轮询场景还叠加了 setTimeout 重试组件卸载后定时器依然在跑请求会持续打给后端新开的页面也会被这些“幽灵请求”拖慢。这个坑的本质是请求取消和定时器清理是两件事必须同时处理。在 React 里推荐的做法是用 AbortController 统一管理。组件卸载时在 effect 的清理函数里调用 abort同时把定时器也放在同一个清理流程里。useEffect(() { const controller new AbortController(); const timer setInterval(() { fetch(/api/status, { signal: controller.signal }) .then(r r.json()) .then(renderStatus) .catch(() {}); }, 5000); return () { clearInterval(timer); controller.abort(); }; }, []);这里 controller.abort() 不仅会中断当前正在执行的 fetch还会让后续的 fetch 直接以失败告终catch 分支可以静默处理。实测下来这是最不容易漏掉的做法因为它把“请求生命周期”和“组件生命周期”绑定在了一起。4.2 坑二并发数拍脑袋设置弱网场景直接排队到超时我见过一个团队把核心页面的接口并发上限设成了 20理由是页面模块多希望首屏更快。结果在弱网环境下一测20 个请求同时发出HTTP/1.1 下同域名连接数只有 6 个剩余 14 个全都进入排队阶段。前面几个大接口响应又慢排队的请求纷纷超时页面比不加并发限制时更慢。这个问题的根源是“并发数”和“连接数”并非同一个概念。浏览器连接数是硬限制超过之后请求只能排队等连接释放。并发池的 limit 应该以“不会让请求在排队阶段滞留过久”为标准而不是“尽量多开任务”。我现在的习惯是先看主要接口的响应时间范围再估算连接数上限最终把并发池设为 4 到 6。如果项目用的是 HTTP/2连接数不再是主要瓶颈但服务端压力仍然在那里4 到 6 依然是合理的起点。排查这个问题的快捷方式并不复杂。打开浏览器开发者工具的 Network 面板看时间线里的每一根请求条如果大部分时间花在 Queueing排队阶段而且颜色特别重那多半就是并发/连接数瓶颈而不是后端慢。4.3 坑三对所有错误都重试打出一个重试风暴重试逻辑写得不对很容易把一个小故障放大成大事故。有一种经典事故链路后端某个接口偶发 0.5% 的超时前端为了提升成功率统一对失败错误重试 3 次间隔只有 200ms。正常情况下没问题但一旦后端因为部署或负载升高进入“半健康”状态0.5% 变成 30%此时前端层层重试实际打到后端的请求翻了 4 到 5 倍后端彻底雪崩。正确的做法是给重试加三个约束。第一只重试“值得重试”的错误比如网络层错误 TypeError: Failed to fetch 和 5xx 服务端错误4xx 一律不允许重试。第二重试间隔必须指数退避而且加随机抖动。第三设置全局重试风暴熔断例如同一个接口在 30 秒内重试次数超过 10 次就暂停该接口的重试直到冷却期结束。在代码层面判断 fetch 错误类型并不复杂但很多人图省事把 catch 到的所有错误都丢进重试逻辑这是最危险的行为。调度器在设计时就应该把错误分类作为重试的前置条件这一条比任何重试公式都重要。4.4 坑四调度器放在组件内部一切换页面就集体重建调度器的生命周期也是一个很容易被忽略的坑。如果把 scheduler 实例写在 React 组件函数体内每次渲染都会新建一个调度器旧调度器里的队列和正在执行的任务全部失去引用。用户快速切换 Tab前一个页面的请求还在跑但已经没有任何代码能取消它们只能等浏览器和服务端自己超时。正确做法是把调度器提到组件之外做成模块级单例或者放进一个独立的 ts 文件。组件卸载时通过 scheduler.cancel 按任务 id 取消属于本组件的任务而不是销毁整个调度器。这样才能既保证任务可取消又避免同一个页面的多个组件用不同调度器互相争抢并发池而失去全局统筹。全局单例的另一个好处是多个页面共用同一个并发池。例如列表页后台在批量下载详情页用户主动刷新共享并发池会让主动刷新拥有更高优先级批量下载让出资源。这就是“调度”比“每个页面各自发请求”更高级之所在。4.5 坑五没有日志出了问题只能靠猜异步请求的排查难度比同步代码高很多。同步代码可以打断点跟局部变量异步请求的链路在任务队列、并发池、重试循环之间来回穿梭出错时往往已经找不到第一现场。我见过不少项目线上用户反馈“功能时好时坏”开发者打开控制台什么都看不到因为生产环境早就把 console 清掉了。我的建议很简单调度器一定要内置可观测性。任务入队时记一条日志任务开始执行时记一条成功时记一条失败时记一条取消时记一条重试时也要记。不需要接很重的监控系统先统一走一个 logger 回调本地开发时打印到控制台生产环境可以上报到已有的监控平台。日志示例type TaskEvent | { type: enqueue; id: string; priority: number } | { type: start; id: string } | { type: success; id: string; cost: number } | { type: failure; id: string; error: unknown } | { type: retry; id: string; attempt: number } | { type: cancel; id: string }; logger?: (event: TaskEvent) void;有了这套日志排查“某个接口为什么反复请求”这类问题时你不再靠猜而是能直接从日志里看到这个任务入队了几次、重试间隔多少、哪一次失败触发了重试、哪一次被调度器主动取消。可观测性是调度器能不能真正用起来的最后一环千万别省。4.6 问题速查表症状可能原因排查切入点解决方向列表显示旧数据过期响应覆盖新响应在 then 回调里打印响应中的请求序号请求取消或序列号丢弃接口全部排队几十秒并发数超过浏览器连接数Network 面板 Queueing 阶段耗时占比降低并发池上限一次弱网导致几十次重试所有错误都触发重试服务端日志请求量暴增按错误类型区分是否重试加指数退避切页面后控制台出现 setState 警告组件卸载未取消请求与定时器React 警告堆栈指向的组件在 effect 清理函数中取消请求页面刷新后旧接口仍在打后端调度器实例随组件销毁刷新前后对比 Network 面板请求数量调度器全局单例按任务 id 取消4.7 一个小技巧把 React 的调度思想借过来聊完具体的坑我分享一个在项目中对我帮助很大的思路React 把任务调度推向极致的方案是“可中断渲染优先级”。它把一次大的渲染工作拆成小片高优先级更新插队低优先级任务可以被打断。我们的请求调度完全可以借鉴同一个理念。比如列表页有首次加载和后台预加载两种请求首次加载优先级是 10预加载优先级是 3。用户向下滚动触发预加载请求时如果此时用户又快速点击了“刷新”按钮调度器应该让刷新请求插队而不是在预加载请求后面干等。你不需要真的支持“中断一个已经发到网络里的请求”只需要在排队阶段让高优先级任务插到队列头部。这一点我们的调度器已经做到了。更深一层也可以在渲染层面配合高优先级请求成功后立刻渲染完整内容低优先级请求成功后只在空闲时把内容补充到页面里避免一次 setState 引发的主线程卡顿。这种前后端联合的“调度思维”和热词里的“ax调度”刚好形成呼应——调度不是某一层的事而是从网络请求到界面更新的完整控制链。5. 写在最后的几点实际体会在我自己维护的项目里调度器从无到有前后只花了一个下午。但就是这几十行代码让“搜索竞态”“并发打满”“不明重试”这三类问题在后续半年里几乎绝迹。每次有新同事来问我该从哪里入手优化接口层我都会建议先做三件事给所有请求加上可取消能力把并发上限管住再定义清楚哪些错误值得重试。这三步比引入任何重型框架都更能止痛。调度器这类东西还有个好处是它有很强的“可移植性”。今天你写前端用的是 fetch 和 AbortController明天切到小程序或者 React Native调度器的队列、优先级、并发池、指数退避这些思路完全通用。换个环境你不需要重新学一套理论只需要换一个请求对象和取消机制。所以花时间把“ax调度”彻底吃透长期来看非常划算。
前端ax调度实战：从请求竞态到并发控制的完整指南
1. 到底什么是“ax调度”从一句玩笑到核心工程问题1.1 “ax调度”这个热词戳中的是每个前端都绕不开的痛点最近技术社区里有个热词叫“ax调度”被不少同事拿来调侃说是资深前端每天的日常就是面红耳赤地跟 ajax 请求搏斗——怎么排队、怎么取消、怎么重试、怎么不把后端打挂。话是玩笑但说得非常实在。如今的前端项目尤其是中后台管理系统和重交互的 C 端应用本质上就是在做一件事把一堆异步事件编排成一个稳定、不跳变、不闪烁的 UI 状态。而“ax”这个缩写在多数人语境里指向 Ajax/Axios 这类异步请求“调度”则是对这些请求的全过程管理。我用一个后厨的例子来解释“调度”到底在调度什么。客人点菜是异步的后厨炒菜也是异步的但出菜口必须有个明确的规则哪一桌的菜先上、哪道菜先做、点菜量太大时怎么排队、某道菜做坏了要重做几次。如果出菜口没有规则高并发下必然会乱套——有的菜凉了有的菜重复上有的客人催了三遍还在等。前端请求调度面对的是同样的局面搜索框每敲一个字就发一次请求多个接口之间存在依赖关系页面切换时旧请求还没返回批量上传时几十个请求同时发出去任何一个环节没有规则用户感知到的就是数据错乱、页面卡顿、按钮一直转圈。所以我一直觉得“ax调度”不是新造的概念而是把以前揉在业务代码里、散落在各个组件里的异步请求管理问题单独拎出来给了个名字。它解决的是“在资源有限、网络不确定、用户操作随机的环境下请求仍然能以正确顺序、合理时效、可控数量完成”的问题。这篇文章的价值在于帮你把这个问题彻底理清适合被请求竞态折腾过的新人也适合想把异步逻辑从组件中剥离出来的老手。1.2 不是只有大项目才需要五个最典型的业务场景有人觉得调度是架构师才考虑的事业务页面不就是发个请求、拿到数据渲染吗真不是。我随手就能列出五个每个前端都写过的场景每一个都在做调度。第一个是搜索联想。用户输入“苹果”可能先触发了一次“苹”再触发一次“苹果”。网络环境下后发的请求可能先返回也可能先发的请求后返回。如果不对响应做处理页面上很可能会出现输入“苹果”却显示“苹”的联想结果。第二个是级联筛选比如先选省份再选城市城市列表依赖省份。如果不做时序控制用户快速切换省份时上一次的请求结果没有及时清掉新旧数据互相覆盖。第三个是批量上传一次选 30 个文件如果 30 个请求同时发出浏览器连接数被占满上传进度和失败重试都不可控。第四个是列表分页用户快速翻页时上一页的请求突然返回把当前页数据覆盖成旧数据表格里出现“灵魂闪现”。第五个是登录后的初始化流程拿 token、拉用户信息、拉权限列表、拉菜单配置彼此之间有先后依赖任何一个失败都会导致后续全部白拉。这些场景单独看都不难但合在一起它们暴露的是同一个本质请求不能只发不管必须有统一的机制来约束“什么时候发”“发几个”“怎么处理过期响应”“失败后怎么办”。这就是调度的核心价值也是为什么“ax调度”能成为一个值得讨论的话题——它看起来不高级但实际项目里八十的线上问题都出在这一层。2. 请求调度要解决的四个基本问题2.1 竞态裁决当响应顺序和发起顺序不一致竞态是异步编程里最常见的坑也是“ax调度”里最优先要解决的问题。网络请求没有保证返回顺序你在时间点 T1 发起请求 A在 T2 发起请求 B但 B 可能比 A 先返回。如果不做处理页面最终显示的是 A 的结果而这个结果早已不是用户最新操作对应的数据。解决竞态最直接的两个思路一个是“取消”一个是“丢弃”。取消的思路是一旦新请求发出就把旧请求真正中止掉。浏览器原生提供一个非常好用的 API叫 AbortController。它的用法很简单const controller new AbortController(); fetch(/api/search?q苹果, { signal: controller.signal }); // 用户继续输入旧请求不再需要 controller.abort();fetch 会监听 signal 上的中断通知中断后本次请求直接失败不会再产生响应。如果用 axios同样支持 signal 参数底层逻辑一致。在实际项目里我一般会封装一个带取消能力的请求函数把 controller 的创建和中止都收敛在一个地方避免每个页面都重复写一遍。function createCancellableRequestT( url: string, options?: RequestInit ) { const controller new AbortController(); return { signal: controller.signal, abort: () controller.abort(), run: async (): PromiseT { const res await fetch(url, { ...options, signal: controller.signal }); return res.json() as PromiseT; } }; }但有时候你不想真正取消因为旧请求的结果可能还有缓存价值比如搜索联想里的热门词结果。这时用“丢弃”策略更合适给每一次请求加一个自增序号响应返回后对比序号如果已经过期就直接忽略。let seq 0; async function search(keyword: string) { const current seq; const res await fetch(/api/search?q${keyword}).then(r r.json()); // 如果期间又发起了新请求当前响应直接丢弃 if (current ! seq) return; renderResult(res); }这个方案虽然简单但工程上非常可靠。我见过很多团队没有做任何竞态保护线上用户反馈“搜索不准确”“筛选乱了”排查到最后都是同一个原因。竞态裁决的核心原则其实就是一句话让用户最新的一次操作决定界面状态其余结果只能让路。2.2 并发控制浏览器和后端都受不了一次全发并发控制说起来也简单不限制当前同时执行的请求数量。为什么必须限制两个原因。第一个是浏览器自身的物理限制。HTTP/1.1 下同一个域名最多只能建立大约 6 个 TCP 连接超出部分会排队等待。如果一个页面同时发 20 个请求后 14 个必须等前面的完成用户直观感受到的就是接口迟迟不返回。第二个原因是服务端压力。哪怕页面和接口都走 HTTP/2多路复用让单域名连接数不再紧张但后端应用服务器依然有线程池、连接池、数据库连接数上限。一次页面操作触发 30 个查询请求数据库可能直接打满整个系统都跟着变慢。所以“并发数”必须显式控制。这里有一个经典的并发池思路核心是维护一个待执行队列和一个“正在执行数量”的计数器。当计数器低于上限时从队列头部取出任务执行每当一个任务完成计数器减一再自动取出下一个任务。async function runWithConcurrencyT( tasks: Array() PromiseT, limit: number ): PromiseT[] { const results: T[] new Array(tasks.length); let index 0; async function worker() { while (index tasks.length) { const current index; results[current] await tasks[current](); } } const workers Array.from( { length: Math.min(limit, tasks.length) }, () worker() ); await Promise.all(workers); return results; }worker 的数量就是并发上限每个 worker 不断从任务数组里取下一个任务取完为止。这个模式的优点在于并不是把 30 个请求同时丢出去而是始终保持最多 N 个在执行。对上传文件、批量初始化这类场景效果立竿见影。具体并发数设多少不要拍脑袋。我一般先看接口耗时和机器配置再从浏览器 Network 面板观察 queueing 阶段的长短。常见项目里 4 到 6 并发是相对稳妥的值既不浪费网络带宽也不会让服务端难堪。注意这个“4 到 6”是经验值不是标准答案最好根据实际并发测试调整。2.3 时序编排接口之间的依赖关系不能靠运气竞态管的是“乱序”并发管的是“数量”时序编排解决的是“依赖”。不少业务接口天生有先后关系先拿登录凭证再拿用户信息最后拿权限列表。这个顺序如果乱了页面轻则报错重则泄露不属于当前用户的菜单和数据。最简单的串行方式就是 await 一个一个等代码很好看但效率偏低。稍微进阶一点的做法是把“并行无关”和“串行依赖”拆开没有依赖关系的接口用 Promise.all 一起发有依赖关系的接口用 await 显式等待前一步完成。const token await fetch(/api/token).then(r r.json()); // 这两个接口互不依赖可以并行 const [userInfo, permissions] await Promise.all([ fetch(/api/user, { headers: { Authorization: Bearer ${token} } }).then(r r.json()), fetch(/api/permissions, { headers: { Authorization: Bearer ${token} } }).then(r r.json()) ]); const menus await fetch(/api/menus?role${permissions.role}).then(r r.json());这里要强调一个容易踩的认知误区很多人喜欢用 Promise.all 处理全部请求觉得“并发”就是快。但 Promise.all 有一个特性任何一个请求失败整体立即 reject其他请求的结果全部丢弃。如果你的场景是“能拿到多少算多少”比如页面首屏由三个独立模块组成其中一个接口挂了其余模块仍然应该显示那就应该用 Promise.allSettled 而不是 Promise.all。还有一点是关于“自动化的依赖编排”。有的项目会引入 DAG 依赖图之类的重型机制去自动分析接口依赖我的实际体会是除非你的接口由可视化编排系统生成否则业务代码里显式写清依赖关系远比自动化推断可靠。因为接口依赖往往夹带着业务状态比如“必须先选中一条记录才能查详情”这类逻辑不在接口参数层面自动化编排根本感知不到强行抽象只会增加复杂度最后还是要手写时序逻辑。2.4 重试与降级调度里最容易玩火的部分重试机制是调度的最后一道防线也是最容易写错的地方。不少人的第一版重试代码是“失败就再来一次”看起来直接但线上常常会因此吃大亏。设想一个场景后端接口因为依赖的数据库连接池打满导致大量请求 5 秒超时如果每个请求失败后立刻重试 3 次原本 100 个请求进来实际打到后端的可能是 400 个后端被进一步压垮形成“重试风暴”。正确做法是对每一次重试做退避也就是让重试间隔随次数指数增长。指数退避的常见公式是延迟时间 基础延迟 × 2 的 n 次方再加上一个随机抖动避免多个请求在同一时刻集体重试。function getBackoffDelay(baseMs: number, attempt: number): number { const exponential baseMs * 2 ** attempt; const jitter Math.random() * 100; return exponential jitter; } // 第 0 次失败后等待约 500ms // 第 1 次失败后等待约 1000ms // 第 2 次失败后等待约 2000ms除了退避还有一个容易忽略的原则不是所有失败都适合重试。HTTP 4xx 这类客户端错误比如参数不对、鉴权失败重试多少次结果都一样反而浪费服务端资源。真正值得重试的是网络层错误和 5xx 服务端错误因为前者可能是临时断网后者可能是短暂的负载高峰。在 fetch 中网络错误通常表现为 TypeError: Failed to fetch判断起来并不难。重试之外还要考虑降级。不是所有请求失败都必须失败到底合理的降级策略能大幅改善用户体验列表接口失败可以展示缓存数据并提示“数据可能不是最新”详情接口失败可以展示骨架屏加一张空状态图权限接口失败可以默认收起所有敏感操作。降级的本质是“在有损状态下仍然给出可用的界面”而不是一直转圈直到用户刷新页面。如果你发现某个接口在持续失败还应该考虑更底层一点的“熔断”思路记录连续失败次数达到阈值后短时间内直接拒绝新的请求不再打到后端等冷却窗口过去再恢复。熔断的细节这里不展开但记住一个结论就够了调度器不仅要管“怎么发请求”更要管“发了之后失败到什么程度必须停手”。3. 自己动手写一个轻量“ax调度器”3.1 先想清楚调度器对外长什么样把上面的机制整合成一个能用的调度器并不需要写出一个复杂的框架。我建议从对外接口开始设计一个调度器至少满足四个诉求并发上限、任务优先级、失败重试、外部取消。我设计的一个最小接口是这样export interface SchedulerTaskT unknown { id: string; priority?: number; // 越大越优先 executor: (signal: AbortSignal) PromiseT; timeout?: number; // 单次执行超时 retries?: number; // 最大重试次数不含首次 baseDelay?: number; // 指数退避的基础延迟 } export interface AxScheduler { addT(task: SchedulerTaskT): PromiseT; cancel(taskId: string): boolean; }调用方使用起来非常直观const scheduler new AxScheduler({ concurrency: 4 }); const result await scheduler.add({ id: user:list, priority: 10, executor: signal fetchUsers(signal), timeout: 5000, retries: 2, baseDelay: 300, });为什么把优先级设计成数字而不是字符串因为数字天然可比较、可排序而字符串最终还要映射成数字才能参与排序。优先级的含义是“当并发池已满时高优先级的任务可以插队先执行”。在业务里这非常有用用户主动点击的操作应当优先于后台的预加载、批量同步等低优先级任务。3.2 优先级队列与并发池的实现调度器内部有两块核心数据结构一个待执行任务队列和一个“当前正在执行的数量”计数器。任务入队后先按优先级排序每次有机会执行时从队列里取出优先级最高的任务开始执行。由于绝大多数场景的任务量不会大到需要引入二叉堆我用数组加线性扫描来挑最大优先级任务代码可读性反而更好。如果你的工程里任务量上万再考虑换成优先队列实现。interface InternalTask { id: string; priority: number; retries: number; baseDelay: number; timeout?: number; executor: (signal: AbortSignal) Promiseunknown; resolve: (value: unknown) void; reject: (reason?: unknown) void; } class AxScheduler { private queue: InternalTask[] []; private activeCount 0; private readonly concurrency: number; constructor(options: { concurrency: number }) { this.concurrency options.concurrency; } addT(task: SchedulerTaskT): PromiseT { return new PromiseT((resolve, reject) { this.queue.push({ id: task.id, priority: task.priority ?? 0, retries: task.retries ?? 0, baseDelay: task.baseDelay ?? 500, timeout: task.timeout, executor: task.executor, resolve: resolve as (value: unknown) void, reject, }); this.next(); }); } cancel(taskId: string): boolean { const index this.queue.findIndex(t t.id taskId); if (index -1) return false; this.queue.splice(index, 1)[0].reject(new Error(task cancelled)); return true; } private next(): void { while (this.activeCount this.concurrency this.queue.length 0) { const bestIndex this.queue.reduce( (best, item, index) item.priority this.queue[best].priority ? index : best, 0 ); const [task] this.queue.splice(bestIndex, 1); this.activeCount; this.execute(task) .then(task.resolve) .catch(task.reject) .finally(() { this.activeCount--; this.next(); }); } } }这段代码里的核心逻辑集中在 next() 方法里。每次有任务完成activeCount 减一然后立刻调用 next() 从队列里补充新任务。因为 while 循环会持续到并发池满或者队列为空所以哪怕同时完成多个任务并发数也不会超限。3.3 竞态取消与超时控制如何接入上面这个版本的调度器还缺两个关键能力单次执行超时以及任务开始后还能被外部取消。超时控制很简单给每个 executor 包一层带 timeout 的 Promise 即可。但注意超时不能只靠 Promise.race 的方式因为真正发出去的 fetch 请求并不会因为外层 Promise 失败而停止必须配合 AbortController 才能把网络请求真正中断。更优雅的方案是让“超时”和“取消”复用同一个 AbortController。统一封一个执行函数private execute(task: InternalTask): Promiseunknown { const controller new AbortController(); let timer: ReturnTypetypeof setTimeout | undefined; if (task.timeout) { timer setTimeout(() controller.abort(), task.timeout); } const promise task.executor(controller.signal) .finally(() { if (timer) clearTimeout(timer); }); // 外部通过 cancel 传入该任务的 signal // 如果 need 取消调用 controller.abort() return promise; }但要支持“按任务 id 取消正在执行的任务”调度器还需要维护一个从 id 到 controller 的映射。我在上一节代码中暂时没有加这个表实际补充很简单在 execute 内部加一个 Map 记录开始时写入结束时删除。如果业务组件在页面卸载时调用 scheduler.cancel(user:list)调度器就会让该任务正在执行的请求直接中断。这样调度器就同时做到了三层取消任务在排队中取消直接从队列移除任务执行中取消中断底层请求任务已取消时重试逻辑自动跳过不再发起新的请求。这三层是竞态保护的地基。3.4 业务里怎么用搜索框和批量导入两个实例有了调度器业务代码可以非常干净。拿搜索联想来举例我只需要在组件里维护一个调度器实例每次输入变化时先把上一次同 id 的任务取消再添加一个新任务。注意在真实项目里调度器应该做成全局单例而不是组件内部 new 一个否则切换组件时正在执行的任务就失去控制了。这里为了展示语义先在组件外创建共享实例。const sharedScheduler new AxScheduler({ concurrency: 6 }); let searchId 0; async function onSearchInput(keyword: string) { const currentId search:${searchId}; sharedScheduler.cancel(search:${searchId - 1}); const data await sharedScheduler.add({ id: currentId, priority: 10, executor: signal fetch(/api/search?q${encodeURIComponent(keyword)}, { signal }) .then(r r.json()), timeout: 3000, }); renderList(data.list); }这个写法最直观的好处是无论用户输入多快上一个请求要么被取消要么返回后被遗弃不会出现“慢请求覆盖快结果”的经典问题。而“搜索联想”这类高频请求占用了并发池时其他页面里的普通请求依然可以正常执行。批量上传场景则更像一个异步任务队列。每次用户选择一批文件就把每个文件封装成单独任务设置较低的优先级限制并发数量。这样不会因为用户一次性选了 20 个文件就把整个浏览器的请求队列占满。const fileScheduler new AxScheduler({ concurrency: 4 }); function uploadFiles(files: File[]) { return Promise.allSettled( files.map((file, index) fileScheduler.add({ id: upload:${Date.now()}:${index}, priority: 5, executor: signal uploadFile(file, signal), timeout: 30000, retries: 2, baseDelay: 1000, }) ) ); }注意这里的返回结果是 Promise.allSettled一个文件失败不会影响其他文件继续上传。调度器内部则通过 timeoute 和 retries 实现了“失败自动重试”用户完全不感知重试过程但上传成功率会明显提升。3.5 调度器设计的取舍与工程边界有一个问题经常被讨论既然已经有 p-limit、p-queue 这些成熟库为什么还要自己写我的观点是生产环境首选成熟库没有任何问题p-queue 甚至原生提供了优先级、并发、超时能力。自己写一遍调度器的价值在于“理解”理解之后你才能判断一个第三方库是否合适、需要怎么配置、出了问题怎么排查。即便最后你用了 p-queue也不影响你对这类问题的认知深度。还要提醒一点调度器只应该管任务的执行机制不要管业务状态。比如“搜索联想结果应该渲染在哪个 div 里”“上传成功后要不要更新列表”这些属于业务层逻辑。如果把业务状态也塞进调度器调度器很快就会变成一个难以维护的“上帝对象”。保持职责单一才能让调度器足够通用、足够稳定。这也是我在实际项目里最深的体会。4. 实际项目中容易踩的五个坑与排查实录4.1 坑一请求是取消了但定时器和内存泄漏没跟着取消先描述一个真实场景页面里有一个轮询接口每 5 秒拉一次最新状态。用户切走页面组件卸载时开发者把轮询定时器清掉了但上一次还没返回的请求没有取消。过了几百毫秒请求返回回调里执行了 setStateReact 在控制台打出那个经典的警告——“对已卸载组件执行状态更新”。更麻烦的是如果轮询场景还叠加了 setTimeout 重试组件卸载后定时器依然在跑请求会持续打给后端新开的页面也会被这些“幽灵请求”拖慢。这个坑的本质是请求取消和定时器清理是两件事必须同时处理。在 React 里推荐的做法是用 AbortController 统一管理。组件卸载时在 effect 的清理函数里调用 abort同时把定时器也放在同一个清理流程里。useEffect(() { const controller new AbortController(); const timer setInterval(() { fetch(/api/status, { signal: controller.signal }) .then(r r.json()) .then(renderStatus) .catch(() {}); }, 5000); return () { clearInterval(timer); controller.abort(); }; }, []);这里 controller.abort() 不仅会中断当前正在执行的 fetch还会让后续的 fetch 直接以失败告终catch 分支可以静默处理。实测下来这是最不容易漏掉的做法因为它把“请求生命周期”和“组件生命周期”绑定在了一起。4.2 坑二并发数拍脑袋设置弱网场景直接排队到超时我见过一个团队把核心页面的接口并发上限设成了 20理由是页面模块多希望首屏更快。结果在弱网环境下一测20 个请求同时发出HTTP/1.1 下同域名连接数只有 6 个剩余 14 个全都进入排队阶段。前面几个大接口响应又慢排队的请求纷纷超时页面比不加并发限制时更慢。这个问题的根源是“并发数”和“连接数”并非同一个概念。浏览器连接数是硬限制超过之后请求只能排队等连接释放。并发池的 limit 应该以“不会让请求在排队阶段滞留过久”为标准而不是“尽量多开任务”。我现在的习惯是先看主要接口的响应时间范围再估算连接数上限最终把并发池设为 4 到 6。如果项目用的是 HTTP/2连接数不再是主要瓶颈但服务端压力仍然在那里4 到 6 依然是合理的起点。排查这个问题的快捷方式并不复杂。打开浏览器开发者工具的 Network 面板看时间线里的每一根请求条如果大部分时间花在 Queueing排队阶段而且颜色特别重那多半就是并发/连接数瓶颈而不是后端慢。4.3 坑三对所有错误都重试打出一个重试风暴重试逻辑写得不对很容易把一个小故障放大成大事故。有一种经典事故链路后端某个接口偶发 0.5% 的超时前端为了提升成功率统一对失败错误重试 3 次间隔只有 200ms。正常情况下没问题但一旦后端因为部署或负载升高进入“半健康”状态0.5% 变成 30%此时前端层层重试实际打到后端的请求翻了 4 到 5 倍后端彻底雪崩。正确的做法是给重试加三个约束。第一只重试“值得重试”的错误比如网络层错误 TypeError: Failed to fetch 和 5xx 服务端错误4xx 一律不允许重试。第二重试间隔必须指数退避而且加随机抖动。第三设置全局重试风暴熔断例如同一个接口在 30 秒内重试次数超过 10 次就暂停该接口的重试直到冷却期结束。在代码层面判断 fetch 错误类型并不复杂但很多人图省事把 catch 到的所有错误都丢进重试逻辑这是最危险的行为。调度器在设计时就应该把错误分类作为重试的前置条件这一条比任何重试公式都重要。4.4 坑四调度器放在组件内部一切换页面就集体重建调度器的生命周期也是一个很容易被忽略的坑。如果把 scheduler 实例写在 React 组件函数体内每次渲染都会新建一个调度器旧调度器里的队列和正在执行的任务全部失去引用。用户快速切换 Tab前一个页面的请求还在跑但已经没有任何代码能取消它们只能等浏览器和服务端自己超时。正确做法是把调度器提到组件之外做成模块级单例或者放进一个独立的 ts 文件。组件卸载时通过 scheduler.cancel 按任务 id 取消属于本组件的任务而不是销毁整个调度器。这样才能既保证任务可取消又避免同一个页面的多个组件用不同调度器互相争抢并发池而失去全局统筹。全局单例的另一个好处是多个页面共用同一个并发池。例如列表页后台在批量下载详情页用户主动刷新共享并发池会让主动刷新拥有更高优先级批量下载让出资源。这就是“调度”比“每个页面各自发请求”更高级之所在。4.5 坑五没有日志出了问题只能靠猜异步请求的排查难度比同步代码高很多。同步代码可以打断点跟局部变量异步请求的链路在任务队列、并发池、重试循环之间来回穿梭出错时往往已经找不到第一现场。我见过不少项目线上用户反馈“功能时好时坏”开发者打开控制台什么都看不到因为生产环境早就把 console 清掉了。我的建议很简单调度器一定要内置可观测性。任务入队时记一条日志任务开始执行时记一条成功时记一条失败时记一条取消时记一条重试时也要记。不需要接很重的监控系统先统一走一个 logger 回调本地开发时打印到控制台生产环境可以上报到已有的监控平台。日志示例type TaskEvent | { type: enqueue; id: string; priority: number } | { type: start; id: string } | { type: success; id: string; cost: number } | { type: failure; id: string; error: unknown } | { type: retry; id: string; attempt: number } | { type: cancel; id: string }; logger?: (event: TaskEvent) void;有了这套日志排查“某个接口为什么反复请求”这类问题时你不再靠猜而是能直接从日志里看到这个任务入队了几次、重试间隔多少、哪一次失败触发了重试、哪一次被调度器主动取消。可观测性是调度器能不能真正用起来的最后一环千万别省。4.6 问题速查表症状可能原因排查切入点解决方向列表显示旧数据过期响应覆盖新响应在 then 回调里打印响应中的请求序号请求取消或序列号丢弃接口全部排队几十秒并发数超过浏览器连接数Network 面板 Queueing 阶段耗时占比降低并发池上限一次弱网导致几十次重试所有错误都触发重试服务端日志请求量暴增按错误类型区分是否重试加指数退避切页面后控制台出现 setState 警告组件卸载未取消请求与定时器React 警告堆栈指向的组件在 effect 清理函数中取消请求页面刷新后旧接口仍在打后端调度器实例随组件销毁刷新前后对比 Network 面板请求数量调度器全局单例按任务 id 取消4.7 一个小技巧把 React 的调度思想借过来聊完具体的坑我分享一个在项目中对我帮助很大的思路React 把任务调度推向极致的方案是“可中断渲染优先级”。它把一次大的渲染工作拆成小片高优先级更新插队低优先级任务可以被打断。我们的请求调度完全可以借鉴同一个理念。比如列表页有首次加载和后台预加载两种请求首次加载优先级是 10预加载优先级是 3。用户向下滚动触发预加载请求时如果此时用户又快速点击了“刷新”按钮调度器应该让刷新请求插队而不是在预加载请求后面干等。你不需要真的支持“中断一个已经发到网络里的请求”只需要在排队阶段让高优先级任务插到队列头部。这一点我们的调度器已经做到了。更深一层也可以在渲染层面配合高优先级请求成功后立刻渲染完整内容低优先级请求成功后只在空闲时把内容补充到页面里避免一次 setState 引发的主线程卡顿。这种前后端联合的“调度思维”和热词里的“ax调度”刚好形成呼应——调度不是某一层的事而是从网络请求到界面更新的完整控制链。5. 写在最后的几点实际体会在我自己维护的项目里调度器从无到有前后只花了一个下午。但就是这几十行代码让“搜索竞态”“并发打满”“不明重试”这三类问题在后续半年里几乎绝迹。每次有新同事来问我该从哪里入手优化接口层我都会建议先做三件事给所有请求加上可取消能力把并发上限管住再定义清楚哪些错误值得重试。这三步比引入任何重型框架都更能止痛。调度器这类东西还有个好处是它有很强的“可移植性”。今天你写前端用的是 fetch 和 AbortController明天切到小程序或者 React Native调度器的队列、优先级、并发池、指数退避这些思路完全通用。换个环境你不需要重新学一套理论只需要换一个请求对象和取消机制。所以花时间把“ax调度”彻底吃透长期来看非常划算。
