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