第一次在CI日志里看到這行報錯時我一度以為是某個第三方ESLint插件新出的規(guī)則。后來翻規(guī)則文檔才發(fā)現(xiàn)這個提示Vue項目里高頻出現(xiàn)的Possible race condition: xxxx might be reassigned based on an outdated value of xxxx其實來自 ESLint 核心規(guī)則require-atomic-updates和Vue本身沒有直接關(guān)系只是Vue項目里太容易踩中了。這條規(guī)則背后涉及的“競態(tài)條件”是前端異步編程里很容易被忽略、但一旦出問題就非常隱蔽的坑。尤其是搜索列表、分頁加載、下拉刷新這類用戶操作頻繁的場景用戶快速連續(xù)操作幾次界面很可能就把舊數(shù)據(jù)顯示成了新數(shù)據(jù)。這篇文章會從報錯本身出發(fā)講清楚這個規(guī)則的判定邏輯、如何在真實組件里復現(xiàn)和驗證競態(tài)然后給出從“先讓它不響”到“真正修復競態(tài)”的完整思路和代碼改造方案。1. 報錯現(xiàn)場構(gòu)建流水線被一條Rule卡住以后1.1 控制臺和CI上出現(xiàn)的完整報錯長什么樣在Vue項目里跑npm run lint或者本地開發(fā)時打開編輯器最常見的展示形式類似下面這樣error Possible race condition: list might be reassigned based on an outdated value of list require-atomic-updates注意結(jié)尾的規(guī)則名require-atomic-updates。報錯里的變量名不是固定的它取決于你的代碼里哪個變量在異步邊界后被重新賦值。我在實際項目中看到過articleList、tableData、searchResult、loading、page這些各種名字都有。報錯位置通常會指向某個async方法里await之后的賦值語句。比如async fetchList() { const { data } await getArticleList(params) this.list data }只要this.list在它自己的作用域里被識別成“共享可變狀態(tài)”這條賦值就可能被規(guī)則標記出來。如果你繼續(xù)往下看ESLint的規(guī)則說明大多只會講“變量在await之后被重新賦值可能導致競爭條件”但到底為什么會有競爭、是不是每個報錯都需要改很多人并不清楚。這也是這篇文章想重點解決的問題。1.2 它來自核心規(guī)則不是Vue或TypeScript插件的專屬規(guī)則排查規(guī)則來源其實很快不需要猜。在項目目錄里執(zhí)行npx eslint --print-config src/views/SearchList.vue輸出的配置對象會列出該文件最終生效的所有規(guī)則和級別。搜索require-atomic-updates你會看到它的級別通常繼承自eslint:recommended也就是ESLint官方推薦規(guī)則集默認級別是error。很多腳手架項目最終都會啟用eslint:recommended所以Vue項目里出現(xiàn)這條規(guī)則并不奇怪。它之所以在Vue項目里出現(xiàn)頻率高主要是因為ESLint的require-atomic-updates檢查的是async函數(shù)而Vue的methods、組合式函數(shù)、Vuex的action里大量使用async/await。開發(fā)時習慣把請求結(jié)果直接賦給 Vue 的響應(yīng)式字段比如this.list data這是一種典型的共享可變狀態(tài)寫入。模板里的事件監(jiān)聽讓用戶操作可以隨時觸發(fā)新的異步調(diào)用天然滿足“并發(fā)調(diào)用”這個前置條件。所以同樣一條規(guī)則在純函數(shù)式代碼里可能很少觸發(fā)在業(yè)務(wù)型Vue項目里就成了高頻報錯。1.3 變量名會變但問題本質(zhì)一致我見過很多同事看到報錯的第一反應(yīng)是去搜索引擎搜“vue eslint Possible race condition”結(jié)果發(fā)現(xiàn)不同文章里示例變量名都不一樣很容易誤以為是不同問題。其實規(guī)則只看代碼形態(tài)一個異步函數(shù)里某個共享狀態(tài)在await之后被重新賦值。所以不管它提示的是list還是data本質(zhì)都是同一個問題。搞清楚這一點之后先別急著改代碼下一步要去理解規(guī)則為什么把“重新賦值”當成潛在風險。2. require-atomic-updates到底在檢查什么2.1 await不是暫停而是并發(fā)交接點很多人對await的理解是“停在這里等結(jié)果出來再繼續(xù)”這個理解在單次調(diào)用里沒問題但在并發(fā)場景下會引人誤解。JavaScript是單線程事件循環(huán)await確實會暫停當前函數(shù)的執(zhí)行但暫停期間事件循環(huán)不會停。用戶可能又觸發(fā)了一次點擊、輸入、滾動另一個異步任務(wù)可能正在更新同一個數(shù)據(jù)。也就是說await的恢復點其實是一個“交接點”當前函數(shù)讓出了執(zhí)行權(quán)其它代碼獲取了執(zhí)行機會等你被恢復時你之前讀過的那些共享狀態(tài)可能已經(jīng)不是原來的值了。打個比方候診室里的座位在你去繳費時可能已經(jīng)被別人占了。你回來后如果還按“之前記得的座位號”直接坐下就坐錯了位置。require-atomic-updates想提醒的就是這種“回到現(xiàn)場后用過期信息覆蓋共享狀態(tài)”的行為。2.2 規(guī)則關(guān)心的代碼形態(tài)共享可變狀態(tài) await后的重新賦值ESLint官方文檔里給出的最簡示例是這樣的let result async function foo() { result await bar() }這里result是一個模塊級的let變量它不屬于某個函數(shù)的局部作用域多個并發(fā)的foo()調(diào)用都會向同一個result寫值。假設(shè)foo()被快速調(diào)用兩次第二次先完成result先被賦值成第二次結(jié)果接著第一次也完成了result又被覆蓋成第一次的結(jié)果。這種情況下最后一次寫入的反而可能是過期數(shù)據(jù)。規(guī)則把這類“跨過await邊界、對共享可變狀態(tài)進行非原子賦值”的行為統(tǒng)一標記為潛在競態(tài)。它不關(guān)心你的賦值表達式是this.list data還是list list.concat(data)只要寫入目標是一個可被多個執(zhí)行流共享的變量就會納入檢查范圍。2.3 規(guī)則不檢測局部變量也不會發(fā)現(xiàn)所有競態(tài)有個容易混淆的點是require-atomic-updates主要針對共享狀態(tài)純函數(shù)內(nèi)的局部const變量一般不會觸發(fā)。例如下面這段代碼通常不會報錯async function fetchList() { const { data } await getList() return data }因為data是局部變量函數(shù)每次調(diào)用都有自己的獨立空間不存在兩個人同時寫同一個data的問題。反過來規(guī)則沒報也不代表沒有競態(tài)。比如 Vuex 里 action 內(nèi)commit的順序錯亂、組件卸載后異步回調(diào)又去修改 DOM、WebSocket 消息多次推送時對同一個數(shù)組做累積更新這些場景規(guī)則不一定能識別但它們同樣是競態(tài)問題。因此這條ESLint規(guī)則更像一個“哨兵提示”而不是“競態(tài)檢測器”?？吹綀箦e需要人工判斷沒看到也不能高枕無憂。2.4 對Vue項目尤其重要的 allowProperties 選項require-atomic-updates有一個選項叫allowProperties。簡單理解默認情況下規(guī)則會檢查類似this.list data這類“對象屬性賦值”如果把allowProperties設(shè)為true規(guī)則只會檢查模塊級普通變量不再對對象屬性賦值報警。Vue項目里大量數(shù)據(jù)都在this上所以這個選項直接決定了Vue項目里此規(guī)則的噪音有多大。在.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 }], }, }, ]設(shè)置之后再跑一遍 lint很多Vue頁面里的this.list data類報錯會消失。但這個選項只是降低規(guī)則的噪音并不會修復真實存在的競態(tài)。因此我更傾向于把它當成一種“評估后的放寬”而不是默認操作。真正要不要放寬應(yīng)該先判斷項目里那些被標記的賦值有沒有可能真的舊覆蓋新。3. 實際組件里的競態(tài)時間線搜索列表復現(xiàn)3.1 一個典型的觸發(fā)場景用一個后臺管理系統(tǒng)常見的搜索列表舉例。用戶在搜索框里輸入關(guān)鍵詞每次輸入都觸發(fā)一次列表請求template input v-modelkeyword inputfetchList placeholder輸入關(guān)鍵詞搜索 / 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是響應(yīng)式共享狀態(tài)searchByKeyword是異步請求await期間用戶完全可以再次輸入并觸發(fā)新的fetchList。ESLint把這個賦值標記出來是因為它無法證明這一刻“舊的響應(yīng)不會晚于新響應(yīng)到達”。3.2 兩次輸入之間發(fā)生了什么假設(shè)用戶快速輸入“vue”和“vue cli”請求發(fā)起和返回的真實時間線可能是這樣的input事件觸發(fā)用戶輸入 “vue”第一個請求req1發(fā)出。用戶繼續(xù)輸入“vue cli”input事件再次觸發(fā)第二個請求req2發(fā)出。后端處理req2更快先返回結(jié)果this.list被賦值為關(guān)鍵詞“vue cli”的數(shù)據(jù)界面顯示正確。后端處理req1稍慢后返回結(jié)果this.list又被改回關(guān)鍵詞“vue”的數(shù)據(jù)界面被舊數(shù)據(jù)覆蓋。從用戶視角來看明明輸入了“vue cli”列表卻顯示了“vue”的結(jié)果。這種問題在本地快速網(wǎng)絡(luò)下不一定能復現(xiàn)因為請求返回順序通常和發(fā)出順序一致一旦上了慢網(wǎng)絡(luò)、弱網(wǎng)環(huán)境或者后端接口本身對不同關(guān)鍵詞處理耗時不一樣問題會頻繁出現(xiàn)。3.3 報錯和真實bug的對應(yīng)關(guān)系在這個例子中ESLint報出的list恰好就是會被舊響應(yīng)覆蓋的那個變量?？梢赃@么理解規(guī)則不是百分百知道你的接口誰快誰慢但它看到了一個足夠危險的代碼形態(tài)于是先報警再由人去判斷。也有一些場景屬于規(guī)則報了、但實際并不會產(chǎn)生問題初始化頁面時只調(diào)用一次不存在并發(fā)觸發(fā)。每次調(diào)用前都有嚴格的狀態(tài)鎖比如if (this.loading) return保證同時只有一個請求在跑。變量是組件私有且組件卸載后不再更新。如果確認屬于這些情況那么規(guī)則報警可以視為誤報或噪聲選擇性地關(guān)閉規(guī)則是合理的。但如果你的代碼像上面搜索列表那樣允許用戶高頻觸發(fā)同一個異步過程就應(yīng)該認真看待這條規(guī)則而不是急著關(guān)掉。4. 從消音到修復四種處理方式的邊界4.1 臨時消音注釋、關(guān)閉規(guī)則、allowProperties對單個位置的代碼可以加行內(nèi)注釋async fetchList() { const { data } await searchByKeyword({ keyword }) // eslint-disable-next-line require-atomic-updates this.list data }也可以全局關(guān)閉module.exports { rules: { require-atomic-updates: off, }, }或者用前面提到的allowProperties: true降低對Vue響應(yīng)式屬性的檢查噪音。這三種都是“讓規(guī)則不再響”的辦法但它們只是讓 lint 通過不會讓競態(tài)消失。適合使用的場景是你已經(jīng)確認這個異步賦值不存在并發(fā)風險或者暫未重構(gòu)但需要先讓CI跑通然后再排期修復。不適合一上來就全局關(guān)掉否則等于把哨兵撤了后面有人寫出真正的競態(tài)代碼也沒人提醒。4.2 偽修復局部變量中轉(zhuǎn)為什么沒有意義網(wǎng)上有一種常見的“修復方案”是先把接口返回值存到一個局部變量再把局部變量賦給this.listasync fetchList() { const { data } await searchByKeyword({ keyword }) const nextList data this.list nextList }這種寫法對規(guī)則來說確實可能降低部分版本的告警概率因為規(guī)則在靜態(tài)分析時不再直接看到“等待后對this.list的讀取和寫入路徑”但它完全沒有解決并發(fā)問題。兩次并發(fā)的請求依然會各自拿到結(jié)果依然會按“誰后返回誰后賦值”的順序覆蓋this.list。所以我在實際操作中不推薦這種改法它只會讓問題更隱蔽。判斷一個修復方式有沒有用不是看ESLint是否還報錯而是看舊響應(yīng)晚到之后UI會不會被錯誤更新。4.3 AbortController讓舊請求直接閉嘴這是從網(wǎng)絡(luò)層解決問題的思路當新請求發(fā)出時直接把還沒返回的舊請求取消掉。舊請求被取消后它的 Promise 會進入 reject 分支后續(xù)賦值代碼不會執(zhí)行界面也就不會被覆蓋。在支持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 } }, }這里的核心邏輯是每次調(diào)用前先把上一次的controllerabort 掉。后續(xù)的await會立即因為你中途 abort 而拋錯于是舊請求的賦值永遠不會執(zhí)行。新請求不受影響正常進入try塊完成賦值。原生fetch用法類似錯誤名稱就是AbortError。如果項目還在用 axios 的CancelToken思路一樣只是錯誤判斷要用axios.isCancel(error)。實測下來這個方案對搜索、篩選、分頁這類高頻觸發(fā)場景效果最好因為舊請求連返回的機會都沒有了服務(wù)端壓力也小一些。4.4 請求令牌模式不依賴取消的兜底有時候請求庫不支持取消或者接口本身已經(jīng)發(fā)出取消也沒有意義。這時候可以用“令牌”來標識請求的時效性每次觸發(fā)新請求時令牌加一。響應(yīng)回來后檢查令牌是否還是當前值如果不是說明已經(jīng)有更新的請求發(fā)生直接丟棄這次結(jié)果。data() { return { requestSeq: 0, list: [], } }, methods: { async fetchList() { const seq this.requestSeq const { data } await searchByKeyword({ keyword: this.keyword }) // 如果期間又發(fā)起了新請求seq 已經(jīng)變化說明這次結(jié)果已過期 if (seq ! this.requestSeq) { return } this.list data }, }這個方案最大的優(yōu)點是底層請求庫無關(guān)fetch、axios、甚至某些 SDK 的異步方法都能用。缺點是沒有真正取消舊請求舊請求仍然會占用網(wǎng)絡(luò)和計算資源只是結(jié)果被丟棄了。和 AbortController 組合使用效果最好先取消舊請求再靠令牌機制兜底雙保險處理那些取消不及時的邊界情況。4.5 四種方式的取舍參考處理方式是否會修復真實競態(tài)適合場景風險單行注釋關(guān)閉否確認無并發(fā)風險的單次初始化掩蓋問題全局關(guān)閉或 allowProperties否整庫評估后有意識地降低噪音后續(xù)新增代碼無人提醒局部變量中轉(zhuǎn)否不推薦隱藏問題甚至不一定會讓 ESLint 恢復安靜AbortController 取消是搜索、篩選、分頁等高并發(fā)依賴請求庫支持 signal請求令牌模式是各類請求 SDK舊請求仍會占用資源取消 令牌組合是高并發(fā)復雜場景代碼量稍多5. 工程化落地請求層統(tǒng)一封裝與驗證5.1 封裝一個“只認最后一次請求”的組合函數(shù)如果每個業(yè)務(wù)函數(shù)里都手寫一遍 AbortController 加 seq 判斷代碼會非常啰嗦而且很容易寫漏。更好的做法是在請求層統(tǒng)一封裝一個工具把競態(tài)策略收斂到一個函數(shù)里。下面是一個 Vue 3 組合式函數(shù)風格的簡化示例核心思想是“取消舊請求 令牌校驗”雙保險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, }) // 令牌校驗防止取消不及時導致舊結(jié)果仍然返回 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創(chuàng)建實例并返回給模板或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() }, }這樣業(yè)務(wù)代碼里既不需要關(guān)心 AbortController 的細節(jié)也不需要維護requestSeq全局計數(shù)每個頁面只需要關(guān)注“拿到最新一次結(jié)果之后怎么渲染”。組件卸載時調(diào)用cancel()也很重要。否則組件已經(jīng)銷毀異步請求返回后可能還會嘗試給已經(jīng)卸載的組件賦值在嚴格模式或配置了部分 lint 規(guī)則時會產(chǎn)生額外警告也會造成無意義的內(nèi)存占用。5.2 為什么要在請求層解決而不是每個頁面單獨處理把競態(tài)策略封裝在組合函數(shù)或請求層工具里最大的好處是行為統(tǒng)一。如果每個頁面自己寫一套有人可能會漏掉取消邏輯有人可能只加一個if判斷最后誰也說不清項目里到底哪些接口還有競態(tài)風險。封裝之后新的頁面只要調(diào)用同一個工具就能夠默認獲得“最新請求優(yōu)先”的語義。另一個好處是便于測試。請求層是純邏輯不依賴具體組件的生命周期?？梢灾苯釉跍y試環(huán)境里模擬兩次快速調(diào)用第一次的返回值晚返回斷言最終數(shù)據(jù)來自第二次調(diào)用。如果競態(tài)邏輯散落在各個組件里測試成本會高出很多。5.3 驗證修復是否真的有效改造之后至少要做兩輪驗證第一輪確認 lint 通過。直接在項目里運行npm run lint此時如果之前只剩這個競態(tài)報錯應(yīng)該已經(jīng)不再出現(xiàn)。如果還有查看是不是同一變量在別的位置還有類似的 await 后賦值。第二輪人工構(gòu)造慢網(wǎng)絡(luò)復現(xiàn)。打開瀏覽器開發(fā)者工具的 Network 面板把網(wǎng)絡(luò)切換成 Slow 3G然后在搜索框里快速輸入兩個不同關(guān)鍵詞觀察請求列表的返回順序。修復前的典型現(xiàn)象是先發(fā)出的請求后返回列表最終顯示舊關(guān)鍵詞結(jié)果。修復后雖然請求仍然可能亂序返回但 UI 最終一定保留最后一次請求的結(jié)果。還可以在fetchList里臨時加打印日志把每次響應(yīng)回來時的keyword和 token 打出來確認過期響應(yīng)確實被丟棄。驗證結(jié)束后再移除調(diào)試日志。5.4 和同體系其它 lint 規(guī)則的配合處理完require-atomic-updates之后項目里同類異步問題還可以通過其它規(guī)則來兜底。比較常見的是typescript-eslint/no-misused-promises它會警告在應(yīng)該處理 Promise 的地方直接傳入了異步函數(shù)能幫助避免一部分“漏捕獲異?！被颉氨O(jiān)聽器里傳 async 函數(shù)”的問題。還有一個no-async-promise-executor檢查new Promise(async () {})這種反模式。它們和require-atomic-updates關(guān)注點不同但都屬于異步邊界上的代碼質(zhì)量防線。不過 lint 規(guī)則始終只是輔助。真正安全的異步代碼還是需要開發(fā)者對“哪些狀態(tài)是共享的、哪些時序可能交錯”有清晰認知。規(guī)則的提示就像是修車廠的檢測燈燈亮了說明有隱患但能不能修好要看你是不是真正理解引擎的工作原理。我自己處理這類報錯的習慣是先不關(guān)規(guī)則打開代碼把await前后那段邏輯通讀一遍。如果確實存在用戶連續(xù)觸發(fā)、響應(yīng)亂序的可能就補上取消或令牌機制如果確認是單次初始化再考慮用注釋或allowProperties降噪。競態(tài)問題不會因為ESLint閉嘴就自動消失它只是暫時不被提醒風險還留在那里。希望這篇文章能幫你在下次看到Possible race condition的時候不再只是搜索“怎么關(guān)閉這個報錯”而是能快速判斷出它到底在保護什么以及你的代碼是不是真的需要修復。