第一次在CI日志里看到这行报错时我一度以为是某个第三方ESLint插件新出的规则。后来翻规则文档才发现这个提示Vue项目里高频出现的Possible race condition: xxxx might be reassigned based on an outdated value of xxxx其实来自 ESLint 核心规则require-atomic-updates和Vue本身没有直接关系只是Vue项目里太容易踩中了。这条规则背后涉及的“竞态条件”是前端异步编程里很容易被忽略、但一旦出问题就非常隐蔽的坑。尤其是搜索列表、分页加载、下拉刷新这类用户操作频繁的场景用户快速连续操作几次界面很可能就把旧数据显示成了新数据。这篇文章会从报错本身出发讲清楚这个规则的判定逻辑、如何在真实组件里复现和验证竞态然后给出从“先让它不响”到“真正修复竞态”的完整思路和代码改造方案。1. 报错现场构建流水线被一条Rule卡住以后1.1 控制台和CI上出现的完整报错长什么样在Vue项目里跑npm run lint或者本地开发时打开编辑器最常见的展示形式类似下面这样error Possible race condition: list might be reassigned based on an outdated value of list require-atomic-updates注意结尾的规则名require-atomic-updates。报错里的变量名不是固定的它取决于你的代码里哪个变量在异步边界后被重新赋值。我在实际项目中看到过articleList、tableData、searchResult、loading、page这些各种名字都有。报错位置通常会指向某个async方法里await之后的赋值语句。比如async fetchList() { const { data } await getArticleList(params) this.list data }只要this.list在它自己的作用域里被识别成“共享可变状态”这条赋值就可能被规则标记出来。如果你继续往下看ESLint的规则说明大多只会讲“变量在await之后被重新赋值可能导致竞争条件”但到底为什么会有竞争、是不是每个报错都需要改很多人并不清楚。这也是这篇文章想重点解决的问题。1.2 它来自核心规则不是Vue或TypeScript插件的专属规则排查规则来源其实很快不需要猜。在项目目录里执行npx eslint --print-config src/views/SearchList.vue输出的配置对象会列出该文件最终生效的所有规则和级别。搜索require-atomic-updates你会看到它的级别通常继承自eslint:recommended也就是ESLint官方推荐规则集默认级别是error。很多脚手架项目最终都会启用eslint:recommended所以Vue项目里出现这条规则并不奇怪。它之所以在Vue项目里出现频率高主要是因为ESLint的require-atomic-updates检查的是async函数而Vue的methods、组合式函数、Vuex的action里大量使用async/await。开发时习惯把请求结果直接赋给 Vue 的响应式字段比如this.list data这是一种典型的共享可变状态写入。模板里的事件监听让用户操作可以随时触发新的异步调用天然满足“并发调用”这个前置条件。所以同样一条规则在纯函数式代码里可能很少触发在业务型Vue项目里就成了高频报错。1.3 变量名会变但问题本质一致我见过很多同事看到报错的第一反应是去搜索引擎搜“vue eslint Possible race condition”结果发现不同文章里示例变量名都不一样很容易误以为是不同问题。其实规则只看代码形态一个异步函数里某个共享状态在await之后被重新赋值。所以不管它提示的是list还是data本质都是同一个问题。搞清楚这一点之后先别急着改代码下一步要去理解规则为什么把“重新赋值”当成潜在风险。2. require-atomic-updates到底在检查什么2.1 await不是暂停而是并发交接点很多人对await的理解是“停在这里等结果出来再继续”这个理解在单次调用里没问题但在并发场景下会引人误解。JavaScript是单线程事件循环await确实会暂停当前函数的执行但暂停期间事件循环不会停。用户可能又触发了一次点击、输入、滚动另一个异步任务可能正在更新同一个数据。也就是说await的恢复点其实是一个“交接点”当前函数让出了执行权其它代码获取了执行机会等你被恢复时你之前读过的那些共享状态可能已经不是原来的值了。打个比方候诊室里的座位在你去缴费时可能已经被别人占了。你回来后如果还按“之前记得的座位号”直接坐下就坐错了位置。require-atomic-updates想提醒的就是这种“回到现场后用过期信息覆盖共享状态”的行为。2.2 规则关心的代码形态共享可变状态 await后的重新赋值ESLint官方文档里给出的最简示例是这样的let result async function foo() { result await bar() }这里result是一个模块级的let变量它不属于某个函数的局部作用域多个并发的foo()调用都会向同一个result写值。假设foo()被快速调用两次第二次先完成result先被赋值成第二次结果接着第一次也完成了result又被覆盖成第一次的结果。这种情况下最后一次写入的反而可能是过期数据。规则把这类“跨过await边界、对共享可变状态进行非原子赋值”的行为统一标记为潜在竞态。它不关心你的赋值表达式是this.list data还是list list.concat(data)只要写入目标是一个可被多个执行流共享的变量就会纳入检查范围。2.3 规则不检测局部变量也不会发现所有竞态有个容易混淆的点是require-atomic-updates主要针对共享状态纯函数内的局部const变量一般不会触发。例如下面这段代码通常不会报错async function fetchList() { const { data } await getList() return data }因为data是局部变量函数每次调用都有自己的独立空间不存在两个人同时写同一个data的问题。反过来规则没报也不代表没有竞态。比如 Vuex 里 action 内commit的顺序错乱、组件卸载后异步回调又去修改 DOM、WebSocket 消息多次推送时对同一个数组做累积更新这些场景规则不一定能识别但它们同样是竞态问题。因此这条ESLint规则更像一个“哨兵提示”而不是“竞态检测器”。看到报错需要人工判断没看到也不能高枕无忧。2.4 对Vue项目尤其重要的 allowProperties 选项require-atomic-updates有一个选项叫allowProperties。简单理解默认情况下规则会检查类似this.list data这类“对象属性赋值”如果把allowProperties设为true规则只会检查模块级普通变量不再对对象属性赋值报警。Vue项目里大量数据都在this上所以这个选项直接决定了Vue项目里此规则的噪音有多大。在.eslintrc.js中配置module.exports { rules: { require-atomic-updates: [error, { allowProperties: true }], }, }如果是新版本的 flat config写法类似import js from eslint/js export default [ js.configs.recommended, { rules: { require-atomic-updates: [error, { allowProperties: true }], }, }, ]设置之后再跑一遍 lint很多Vue页面里的this.list data类报错会消失。但这个选项只是降低规则的噪音并不会修复真实存在的竞态。因此我更倾向于把它当成一种“评估后的放宽”而不是默认操作。真正要不要放宽应该先判断项目里那些被标记的赋值有没有可能真的旧覆盖新。3. 实际组件里的竞态时间线搜索列表复现3.1 一个典型的触发场景用一个后台管理系统常见的搜索列表举例。用户在搜索框里输入关键词每次输入都触发一次列表请求template input v-modelkeyword inputfetchList placeholder输入关键词搜索 / ul li v-foritem in list :keyitem.id{{ item.name }}/li /ul /template script import { searchByKeyword } from /api/search export default { data() { return { keyword: , list: [], } }, methods: { async fetchList() { const keyword this.keyword const { data } await searchByKeyword({ keyword }) // ESLint 可能在这里报 // Possible race condition: list might be reassigned based on an outdated value of list this.list data }, }, } /script这段代码核心问题在于this.list是响应式共享状态searchByKeyword是异步请求await期间用户完全可以再次输入并触发新的fetchList。ESLint把这个赋值标记出来是因为它无法证明这一刻“旧的响应不会晚于新响应到达”。3.2 两次输入之间发生了什么假设用户快速输入“vue”和“vue cli”请求发起和返回的真实时间线可能是这样的input事件触发用户输入 “vue”第一个请求req1发出。用户继续输入“vue cli”input事件再次触发第二个请求req2发出。后端处理req2更快先返回结果this.list被赋值为关键词“vue cli”的数据界面显示正确。后端处理req1稍慢后返回结果this.list又被改回关键词“vue”的数据界面被旧数据覆盖。从用户视角来看明明输入了“vue cli”列表却显示了“vue”的结果。这种问题在本地快速网络下不一定能复现因为请求返回顺序通常和发出顺序一致一旦上了慢网络、弱网环境或者后端接口本身对不同关键词处理耗时不一样问题会频繁出现。3.3 报错和真实bug的对应关系在这个例子中ESLint报出的list恰好就是会被旧响应覆盖的那个变量。可以这么理解规则不是百分百知道你的接口谁快谁慢但它看到了一个足够危险的代码形态于是先报警再由人去判断。也有一些场景属于规则报了、但实际并不会产生问题初始化页面时只调用一次不存在并发触发。每次调用前都有严格的状态锁比如if (this.loading) return保证同时只有一个请求在跑。变量是组件私有且组件卸载后不再更新。如果确认属于这些情况那么规则报警可以视为误报或噪声选择性地关闭规则是合理的。但如果你的代码像上面搜索列表那样允许用户高频触发同一个异步过程就应该认真看待这条规则而不是急着关掉。4. 从消音到修复四种处理方式的边界4.1 临时消音注释、关闭规则、allowProperties对单个位置的代码可以加行内注释async fetchList() { const { data } await searchByKeyword({ keyword }) // eslint-disable-next-line require-atomic-updates this.list data }也可以全局关闭module.exports { rules: { require-atomic-updates: off, }, }或者用前面提到的allowProperties: true降低对Vue响应式属性的检查噪音。这三种都是“让规则不再响”的办法但它们只是让 lint 通过不会让竞态消失。适合使用的场景是你已经确认这个异步赋值不存在并发风险或者暂未重构但需要先让CI跑通然后再排期修复。不适合一上来就全局关掉否则等于把哨兵撤了后面有人写出真正的竞态代码也没人提醒。4.2 伪修复局部变量中转为什么没有意义网上有一种常见的“修复方案”是先把接口返回值存到一个局部变量再把局部变量赋给this.listasync fetchList() { const { data } await searchByKeyword({ keyword }) const nextList data this.list nextList }这种写法对规则来说确实可能降低部分版本的告警概率因为规则在静态分析时不再直接看到“等待后对this.list的读取和写入路径”但它完全没有解决并发问题。两次并发的请求依然会各自拿到结果依然会按“谁后返回谁后赋值”的顺序覆盖this.list。所以我在实际操作中不推荐这种改法它只会让问题更隐蔽。判断一个修复方式有没有用不是看ESLint是否还报错而是看旧响应晚到之后UI会不会被错误更新。4.3 AbortController让旧请求直接闭嘴这是从网络层解决问题的思路当新请求发出时直接把还没返回的旧请求取消掉。旧请求被取消后它的 Promise 会进入 reject 分支后续赋值代码不会执行界面也就不会被覆盖。在支持signal的请求库中比如 axios 0.22 以上版本可以这样写data() { return { controller: null, list: [], } }, methods: { async fetchList() { if (this.controller) { this.controller.abort() } const controller new AbortController() this.controller controller try { const { data } await searchByKeyword( { keyword: this.keyword }, { signal: controller.signal } ) this.list data } catch (error) { // 旧请求被取消时直接忽略错误 if (error.name AbortError || error.code ERR_CANCELED) { return } throw error } }, }这里的核心逻辑是每次调用前先把上一次的controllerabort 掉。后续的await会立即因为你中途 abort 而抛错于是旧请求的赋值永远不会执行。新请求不受影响正常进入try块完成赋值。原生fetch用法类似错误名称就是AbortError。如果项目还在用 axios 的CancelToken思路一样只是错误判断要用axios.isCancel(error)。实测下来这个方案对搜索、筛选、分页这类高频触发场景效果最好因为旧请求连返回的机会都没有了服务端压力也小一些。4.4 请求令牌模式不依赖取消的兜底有时候请求库不支持取消或者接口本身已经发出取消也没有意义。这时候可以用“令牌”来标识请求的时效性每次触发新请求时令牌加一。响应回来后检查令牌是否还是当前值如果不是说明已经有更新的请求发生直接丢弃这次结果。data() { return { requestSeq: 0, list: [], } }, methods: { async fetchList() { const seq this.requestSeq const { data } await searchByKeyword({ keyword: this.keyword }) // 如果期间又发起了新请求seq 已经变化说明这次结果已过期 if (seq ! this.requestSeq) { return } this.list data }, }这个方案最大的优点是底层请求库无关fetch、axios、甚至某些 SDK 的异步方法都能用。缺点是没有真正取消旧请求旧请求仍然会占用网络和计算资源只是结果被丢弃了。和 AbortController 组合使用效果最好先取消旧请求再靠令牌机制兜底双保险处理那些取消不及时的边界情况。4.5 四种方式的取舍参考处理方式是否会修复真实竞态适合场景风险单行注释关闭否确认无并发风险的单次初始化掩盖问题全局关闭或 allowProperties否整库评估后有意识地降低噪音后续新增代码无人提醒局部变量中转否不推荐隐藏问题甚至不一定会让 ESLint 恢复安静AbortController 取消是搜索、筛选、分页等高并发依赖请求库支持 signal请求令牌模式是各类请求 SDK旧请求仍会占用资源取消 令牌组合是高并发复杂场景代码量稍多5. 工程化落地请求层统一封装与验证5.1 封装一个“只认最后一次请求”的组合函数如果每个业务函数里都手写一遍 AbortController 加 seq 判断代码会非常啰嗦而且很容易写漏。更好的做法是在请求层统一封装一个工具把竞态策略收敛到一个函数里。下面是一个 Vue 3 组合式函数风格的简化示例核心思想是“取消旧请求 令牌校验”双保险import { ref } from vue export function useLatestRequest(requestFn) { let seq 0 let controller null async function run(...args) { // 取消上一个请求 if (controller) { controller.abort() } controller new AbortController() const current seq try { const data await requestFn(...args, { signal: controller.signal, }) // 令牌校验防止取消不及时导致旧结果仍然返回 if (current ! seq) { return undefined } return data } catch (error) { if ( error.name AbortError || error.code ERR_CANCELED || current ! seq ) { return undefined } throw error } } function cancel() { seq if (controller) { controller.abort() } } return { run, cancel } }在组件中可以通过setup创建实例并返回给模板或methods使用import { useLatestRequest } from /utils/useLatestRequest import { searchByKeyword } from /api/search export default { setup() { const latestSearch useLatestRequest(searchByKeyword) return { latestSearch, } }, data() { return { keyword: , list: [], } }, methods: { async fetchList() { const data await this.latestSearch.run({ keyword: this.keyword }) if (data) { this.list data } }, }, beforeUnmount() { this.latestSearch.cancel() }, }这样业务代码里既不需要关心 AbortController 的细节也不需要维护requestSeq全局计数每个页面只需要关注“拿到最新一次结果之后怎么渲染”。组件卸载时调用cancel()也很重要。否则组件已经销毁异步请求返回后可能还会尝试给已经卸载的组件赋值在严格模式或配置了部分 lint 规则时会产生额外警告也会造成无意义的内存占用。5.2 为什么要在请求层解决而不是每个页面单独处理把竞态策略封装在组合函数或请求层工具里最大的好处是行为统一。如果每个页面自己写一套有人可能会漏掉取消逻辑有人可能只加一个if判断最后谁也说不清项目里到底哪些接口还有竞态风险。封装之后新的页面只要调用同一个工具就能够默认获得“最新请求优先”的语义。另一个好处是便于测试。请求层是纯逻辑不依赖具体组件的生命周期。可以直接在测试环境里模拟两次快速调用第一次的返回值晚返回断言最终数据来自第二次调用。如果竞态逻辑散落在各个组件里测试成本会高出很多。5.3 验证修复是否真的有效改造之后至少要做两轮验证第一轮确认 lint 通过。直接在项目里运行npm run lint此时如果之前只剩这个竞态报错应该已经不再出现。如果还有查看是不是同一变量在别的位置还有类似的 await 后赋值。第二轮人工构造慢网络复现。打开浏览器开发者工具的 Network 面板把网络切换成 Slow 3G然后在搜索框里快速输入两个不同关键词观察请求列表的返回顺序。修复前的典型现象是先发出的请求后返回列表最终显示旧关键词结果。修复后虽然请求仍然可能乱序返回但 UI 最终一定保留最后一次请求的结果。还可以在fetchList里临时加打印日志把每次响应回来时的keyword和 token 打出来确认过期响应确实被丢弃。验证结束后再移除调试日志。5.4 和同体系其它 lint 规则的配合处理完require-atomic-updates之后项目里同类异步问题还可以通过其它规则来兜底。比较常见的是typescript-eslint/no-misused-promises它会警告在应该处理 Promise 的地方直接传入了异步函数能帮助避免一部分“漏捕获异常”或“监听器里传 async 函数”的问题。还有一个no-async-promise-executor检查new Promise(async () {})这种反模式。它们和require-atomic-updates关注点不同但都属于异步边界上的代码质量防线。不过 lint 规则始终只是辅助。真正安全的异步代码还是需要开发者对“哪些状态是共享的、哪些时序可能交错”有清晰认知。规则的提示就像是修车厂的检测灯灯亮了说明有隐患但能不能修好要看你是不是真正理解引擎的工作原理。我自己处理这类报错的习惯是先不关规则打开代码把await前后那段逻辑通读一遍。如果确实存在用户连续触发、响应乱序的可能就补上取消或令牌机制如果确认是单次初始化再考虑用注释或allowProperties降噪。竞态问题不会因为ESLint闭嘴就自动消失它只是暂时不被提醒风险还留在那里。希望这篇文章能帮你在下次看到Possible race condition的时候不再只是搜索“怎么关闭这个报错”而是能快速判断出它到底在保护什么以及你的代码是不是真的需要修复。