上周我花了整整三天排查一个线上故障最后发现根子竟然是最常见的异步请求顺序问题。这个项目我内部代号叫 Rea——一个只解决异步竞态的小工具。起因是某跨平台系统的列表页用户快速切换筛选条件时旧的接口响应偶尔会覆盖新的响应页面数据跟着串场。如果你也遇到过“先发的请求后回来”“页面偶尔闪一下旧数据”“loading 状态莫名被关掉”这类诡异问题这篇把竞态条件Race Condition从现象、原理、排查到根治一次讲透适合所有写前端异步逻辑的开发者参考。1. 一次线上故障让我把竞态处理当成正经事来干1.1 故障现场导出回执配错了订单批次先还原一下当时的场景。某跨平台系统里有一个订单导出功能用户选择日期范围、订单状态、门店编号之后点击“导出”后端会异步生成文件几分钟后通过消息通知用户下载。上线后的第三天客服陆续收到同一类反馈用户明明只导出了 A 批次的数据收到的回执里却是 B 批次的内容。一开始我们怀疑后端搞混了导出任务查了后端日志、消息队列消费记录、导出任务表全部正常单次调用也没问题。后来我在测试环境连续快速点击导出按钮才终于抓到猫腻前端连续创建两个导出任务时第二个任务返回的“回执通知”会覆盖第一个任务的状态回调导致页面把两个任务信息混着用。这已经不是后端的问题了是前端异步处理响应时发生了典型的竞态。1.2 排查路径从后端追到前端的三个线索那三天我梳理了一个比较完整的排查链路先卡死后端接口层所有任务创建都是同步返回任务 ID没有乱序消息队列按用户维度消费任务状态更新有幂等控制数据库记录里两个任务的数据完全没有交叉污染。后端干干净净那就只能往前端找。我重新在浏览器里录制了整个操作过程打开了网络面板盯着瀑布图看了很多遍找到三个线索第一用户点击导出后前端会先发一个“创建任务”的请求拿到任务 ID 后再轮询“任务状态”第二快速点击时轮询请求是按顺序发出的但浏览器里显示下拉刷新时它们的完成时间完全是乱的第三我把网络限速调到最慢之后旧任务的轮询结果反而比新任务更晚回来回调里拿当前任务 ID 去更新全局状态就把新任务的状态覆盖了。到这里我终于确认这不是后端问题也不是简单的“重复提交”而是请求响应乱序导致的竞态条件。1.3 为什么“先发不一定先至”竞态这个词听起来玄乎其实用快递类比特别好懂两辆快递车同时出发先出发的那辆可能因为绕路、堵车晚到后出发的上了高速反而先到。网络请求也是一样微服务调用链路、网关转发、CDN 缓存、设备网络抖动都会让响应时长变得不可控。所以异步代码里有一个铁律请求发出的顺序绝不代表响应回来的顺序。谁先回来谁后回来取决于每一跳的处理速度。我们写的回调函数拿到的只是“一个响应”如果不主动去校验“这个响应属于谁”就很容易让旧响应覆盖新响应最终表现为数据错乱。2. 竞态条件的本质解剖别把所有锅都甩给网络很多人一听竞态就想到网络其实竞态在代码里无处不在。我把平时遇到的竞态归纳成三层请求层、业务层、渲染层。理解这三层才能对症下药。2.1 请求层的“口水战”旧响应覆盖新响应最典型的就是搜索框。用户输入“苹果”发出请求 A再输入“香蕉”发出请求 B。A 的接口比较慢B 的接口比较快B 先回来A 后回来最后页面显示的是“苹果”的搜索结果但输入框里明明是“香蕉”。代码长这样async function onSearch(keyword) { const data await fetch(/api/search?q${keyword}); setResult(data); // 谁先回来不重要关键是最后谁把结果写进去 }这种写法天生就有竞态隐患。setResult不关心数据是谁的只管把数据塞进状态。两个请求并发时最后塞进去的可能是旧数据。很多前端新手遇到这个问题第一反应是“后端接口太慢”多加点 loading 动画其实治标不治本loading 结束之后数据照样错。2.2 业务层的共享可变状态loading、缓存、分页游标请求层的竞态比较容易被发现业务层的就隐蔽多了。我举个例子页面上有两个并发请求一个查列表一个查详情共用一个全局 loading 状态。列表请求先发出但后回来详情请求后发出但先回来。详情请求回来时loading 被置为 false列表请求返回之后如果按照同样的逻辑把 loading 也置为 false看起来没问题。可如果列表请求里有一段逻辑拿到数据后要写入本地缓存并且更新一个“最近更新时间”字段刚好这个字段又被另一个模块读取那就会出现“A 请求的数据带着更晚的时间戳覆盖掉 B 请求的数据”缓存直接错乱。分页游标也是重灾区。列表下翻加载第二页时用户又快速切换了筛选条件。第一页的游标、第二页的游标、新筛选条件的游标三个请求几乎同时飞出去响应顺序完全随机。如果代码里直接拿旧游标追加数据分页数据就会混进不同筛选条件下的记录。2.3 渲染层的竞态列表闪烁、图表抖动和“幽灵状态”到了 React、Vue 这类响应式框架里竞态会和组件生命周期纠缠在一起。最常见的报错是“Cant perform a React state update on an unmounted component”。组件卸载之后异步回调仍然执行了 setState。React 17 以下会直接报警告React 18 之后虽然警告弱化了但底层的问题还在回调的闭包捕获了第一次渲染时的 props 和 state用旧值去更新新界面。具体表现是用户从列表页跳进详情页详情页还在加载时用户又立刻返回列表页。详情请求回来后回调里 setState 一个已经不存在的组件实例或者把一个过期的 loading 状态写进共享状态。这种“幽灵状态”特别难查因为界面可能只闪一下或者只在特定机型、特定网络下出现。本质上还是响应乱序叠加了组件生命周期导致状态被没有资格写入的一方篡改。3. 实战复盘某跨平台系统的“列表筛选竞态”是怎么抓出来的3.1 现象还原图表比表格慢半拍这次故障来自另一个模块一个 B 端数据看板。页面上有城市筛选、日期范围、业务线三个维度筛选条件一变同时发三个请求表格数据、图表聚合数据、汇总卡片数据。上线后测试反馈一个偶现问题表格数据已经更新成新条件了图表还是旧条件的。尤其是快速把日期范围从“近 30 天”切到“近 7 天”再切回“近 30 天”时图表有较高概率显示的是第二次切换之前的内容。一开始大家以为是图表组件缓存问题因为表格重新请求了图表看着像走了本地缓存。后来把接口响应时间打出来才发现图表接口因为聚合逻辑复杂平均响应时间比表格慢 300 到 800 毫秒。用户切完条件表格先渲染新数据图表接口才姗姗回来结果拿着旧条件的响应把新图表覆盖了。3.2 排查三件套网络面板、Performance 时间线、日志插桩我排查这类问题有一套固定的“三件套”第一件网络面板。打开浏览器开发者工具切到 Network筛选 XHR/Fetch把录制的交互过程里的请求按“完成时间”排序而不是按“发起时间”排序。这样能直观看到响应乱序。这一步能快速判断到底是不是“先发后至”。第二件Performance 时间线。用录制功能记录一次完整的筛选切换操作能看到每个请求的开始时间、结束时间、渲染阻塞情况。这对确认“数据更新到 UI 的先后顺序”很有帮助因为有时候接口没问题是渲染队列把任务排到后面了。第三件日志插桩。这个最关键也最容易被忽略。给每个请求加一个 requestId打印出发起时间和返回时间同时打印当前页面上的筛选条件快照。代码大概长这样const requestId globalRequestCounter; console.log([req ${requestId}] start, getFilterSnapshot()); fetchData().then(() { console.log([req ${requestId}] done, getFilterSnapshot()); // 处理数据 });通过日志时间轴就能精确判断哪个响应在返回时“顺手污染”了当前状态。3.3 复现方法限速、条件断点、延迟注入定位竞态问题复现是最大的难点。很多时候你盯着页面看半天它偏偏不犯错。我的做法是人为制造乱序在开发者工具的网络面板里设置较慢的限速档位把网络环境模拟成 3G 水平然后快速切换筛选条件。这个方法能显著放大竞态出现的概率。更进一步在本地 mock 层给不同接口加随机延迟。比如表格接口延迟 100 到 300 毫秒图表接口延迟 800 到 1500 毫秒人为制造“你有你的节奏我有我的节奏”的效果。然后打条件断点当响应数据里的 requestId 不等于当前最新的 requestId 时断住程序观察调用栈。这一步能直接把竞态发生的位置从“抽象的感觉”变成“具体的代码行”。3.4 定位结论三个竞态点叠加才是真正的“坑王”排查到最后我发现问题不是单点故障而是三个竞态点叠加在一起竞态点一接口响应本身乱序旧数据覆盖新数据竞态点二页面全局筛选状态被多段代码同时读写没有统一的“最新条件”权威源竞态点三前端引入了本地缓存代理缓存写入时机和响应返回时机绑定导致旧条件的数据被当成新条件数据缓存。这三个点单独拆开看每一个都不难解决但它们叠加在一起就会表现出“修好一个另一个又冒出来”的诡异状态。所以我没有继续打补丁而是回头做了一个统一处理方案也就是后面要说的 Rea 工具。4. 五种修复方案的对比以及我最终选定的组合拳竞态的修复方案业界有很多我在这里把常用的几种都列出来对比一下适用场景和代价再讲我最后选定的组合。4.1 方案 A取消旧请求原理是发出新请求时把上一个还没完成的请求直接取消。浏览器原生提供了 AbortControlleraxios 也支持 cancelToken。let controller null; async function onSearch(keyword) { controller?.abort(); controller new AbortController(); try { const data await fetch(/api/search?q${keyword}, { signal: controller.signal }); setResult(data); } catch (e) { if (e.name AbortError) return; // 被取消忽略 throw e; } }这种方案最适合“动作触发型”场景比如导出按钮、支付按钮、保存按钮。用户连续点导出时取消旧任务能省掉无谓的轮询请求。缺点是后端可能已经开始处理旧请求前端取消只是不再处理响应真正的“取消”需要在后端配合实现幂等。4.2 方案 B请求序号标记法用一个递增的序号响应回来时只处理最新序号对应的那次。这个方案兼容性最好哪怕是不支持 AbortController 的旧浏览器也能跑。let seq 0; async function onSearch(keyword) { const currentSeq seq; const data await fetch(/api/search?q${keyword}); if (currentSeq ! seq) return; // 已经不是最新请求丢弃 setResult(data); }这种方案对输入触发型场景非常友好搜索框、筛选条件、分页翻页都适用。它不会节省流量但能保证状态不被旧响应污染。实现成本极低我几乎每次遇到竞态都会先加这个。4.3 方案 C串行化队列把请求改为绝对有序前一个请求完成之后再发下一个请求。这种方式能彻底杜绝乱序但缺点也很明显速度慢请求会排队等待不适合高频触发的场景。我一般只在写操作里用比如必须严格按顺序执行的批量保存操作或者对顺序敏感的轮询逻辑。4.4 方案 D业务层状态机 / 快照对比记录发起请求时的筛选条件快照响应返回后对比当前条件和快照是否一致。这个方法本质上是“响应归属校验”比 requestId 更贴近业务。比如let lastFilter null; async function fetchWithFilter(filter) { lastFilter filter; const data await fetchByFilter(filter); if (JSON.stringify(lastFilter) ! JSON.stringify(filter)) return; setData(data); }这种方案的优点是不用管请求是谁发起的只关心“当前这条数据还符不符合用户正在看的场景”非常直观。缺点是需要业务自行构造快照字段比较逻辑写不好也会出问题。4.5 组合拳Rea 工具的核心设计我在实践里没有只选一种而是把 B 和 D 结合再包上一层可选取消能力做成了 Rea。Rea 核心只有一个概念每一次任务执行都会刷新“代数”回调或响应回来时如果“代数”已经过期就丢弃结果。核心代码用 TypeScript 写大概是这样export function createRaceGuard() { let generation 0; let controller: AbortController | null null; return { async runT( task: (signal: AbortSignal) PromiseT, fallback?: () void ): PromiseT | undefined { generation 1; const current generation; controller?.abort(); controller new AbortController(); try { const result await task(controller.signal); if (current ! generation) { fallback?.(); return undefined; // 过期结果直接丢弃 } return result; } catch (err) { if (current ! generation) { fallback?.(); return undefined; // 被新任务打断造成的失败不算错误 } throw err; } } }; }用法很简单const guard createRaceGuard(); async function onFilterChange(filter) { const data await guard.run((signal) fetchData(filter, { signal })); if (data) { setTable(data.table); setChart(data.chart); } }这里把“取消旧请求”和“丢弃过期结果”合二为一。旧的请求会被 abort 掉极端情况下 abort 事件和响应事件同时触发generation 检查也能兜住保证状态只被最新一次操作写入。加了 fallback 之后还能在丢弃旧结果时做一些额外清理比如关闭专属 loading。我还把 Rea 封装成了 React Hook 版本配合 useEffect 处理页面卸载的场景function useRaceGuard() { const guardRef useRefReturnTypetypeof createRaceGuard(); if (!guardRef.current) { guardRef.current createRaceGuard(); } useEffect(() { const guard guardRef.current; return () { guard.run(() Promise.resolve()); // 触发一次新代数使未完成响应全部过期 }; }, []); return guardRef.current; }使用的时候在组件卸载时调用一次所有未完成的异步回调都会因为代数不匹配而被丢弃从根上避免 setState on unmounted 问题。5. 把经验沉淀成规范竞态防护清单与常见误区解决了两个项目之后我把经验沉淀成一份清单贴在团队每个涉及异步请求的模块的评审清单里。5.1 这份清单我贴在每个模块的 PRD 评审里下面的检查项每个都踩过坑所有异步请求在更新状态之前必须校验“本次响应是否仍然代表当前最新请求”。不管用请求序号、快照还是 AbortController至少要选一种。按钮触发型操作必须防重复提交。手段可以是禁用按钮、防抖、或者给请求加幂等令牌。列表筛选、分页、搜索这类高频触发场景必须处理“旧响应覆盖新响应”的问题。组件卸载时必须停止所有异步状态的写入。要么走 abort要么走代数过期不能裸写 setState。全局状态库例如 Redux、Pinia里的异步 action必须自带竞态防护不能指望每个调用者都记得处理。缓存代理层写入数据时要附加时间戳或版本号。读取缓存时校验版本避免旧缓存污染新页面。5.2 三个让人迷惑的“假竞态”在排查过程中我还遇到过三个看起来很像是竞态、其实不是的情况列出来免得大家走弯路第一个是“防抖导致的数据延迟”。用户已经停止输入了防抖计时器还在跑晚 300 毫秒后才发请求。这时候如果页面先用旧数据渲染了一次又用新数据渲染第二次看起来像竞态其实是防抖参数不合理。这类问题和竞态的复现手段完全不同调一调 debounce 延迟就能解决。第二个是“服务端同步返回导致的前端覆盖”。有的后端接口虽然是异步任务但在内部做了同步等待响应时间就是比另一个接口长。前端需要拉的接口多时晚到的接口总是携带更旧的条件参数。这种问题要从接口合并或请求编排入手而不是单靠前端丢弃响应。第三个是“偶现”这个特征本身。不少测试觉得“偶尔出现一次刷新就好了”就不算 bug。但竞态的典型特征就是偶现网络波动一大就出现波动一缓就消失。遇到这种反馈别急着关单先按照限速复现的方法测一轮。我用一张表总结真竞态和假竞态的差异对比项真竞态假竞态防抖/缓存/依赖顺序问题触发条件异步响应乱序、并发操作固定延迟、缓存读取时序复现方式限速快速操作调整延迟参数可稳定复现表现特征数据随机错乱、偶现每次复现结果大致一致修复思路取消/丢弃过期响应调整业务逻辑或参数5.3 测试与压测验证防护是否有效的小技巧修复完竞态之后怎么证明真的修好了我习惯做三层验证。第一层单元测试。手写一个可以手动控制 Promise 状态的工具先发起请求 A再发起请求 B然后先 resolve B再 resolve A最后断言页面状态是 B 的结果。这一步能直接验证 Rea 的代数机制是否生效。第二层集成测试。用浏览器扩展拦截请求给不同的接口注入不同的延迟。筛选条件切换后让图表接口比表格接口晚 1 秒返回检查最终 UI 是否是正确的组合。第三层压力测试。把网络限速调到最慢档快速切换筛选条件 20 次观察控制台有没有异常UI 有没有错乱。如果 20 次都没问题基本可以放心上线。这里有个小技巧随机延迟比固定延迟更能暴露竞态。因为竞态的本质是随机性你用固定延迟只能复现某一种乱序随机延迟却能覆盖各种排列组合。5.4 写在最后我现在写异步代码的固定动作经过这几轮折腾我现在写任何一段异步代码都会先问自己三个问题这个响应回来的时候用户还停留在这个页面吗这个响应里的数据和用户当前看到的筛选条件是一致的吗如果有多个请求同时飞出去最终谁负责写入哪一个状态如果回答过程中有任何犹豫我就会把 Rea 套上去或者至少加一个请求序号检查。这不复杂但能省掉后面无数个加班的夜晚。异步竞态不像语法错误那样有一个报错信息告诉你错在哪它总是悄无声息地破坏数据。你只有从机制上把它堵死才能真正睡得安稳。
)
