做過幾次Vue3項(xiàng)目之后你會發(fā)現(xiàn)一個(gè)現(xiàn)象很多同學(xué)能把Vue3的API背得滾瓜爛熟reactive、ref、computed張口就來但一遇到數(shù)據(jù)明明改了視圖就是不動的問題就開始瞎猜亂試。根子上的原因就是對響應(yīng)式系統(tǒng)只有模糊的感覺沒有真正理解它內(nèi)部的角色分工和數(shù)據(jù)流向。這篇文章打算把Vue3響應(yīng)式系統(tǒng)掰開揉碎講清楚從設(shè)計(jì)思路、Proxy與Reflect的配合、track和trigger依賴收集機(jī)制到reactive、ref、computed的具體實(shí)現(xiàn)再到實(shí)際項(xiàng)目中我踩過的坑和排查技巧一條線拉通。適合正在學(xué)Vue3的人、準(zhǔn)備面試的人以及已經(jīng)被響應(yīng)式問題坑過幾次的開發(fā)者?？赐曛竽悴粌H能答上面試題還能真正寫出符合響應(yīng)式原理的代碼排查問題時(shí)也有方向了。1. 響應(yīng)式系統(tǒng)的整體設(shè)計(jì)與定位1.1 從Vue2到Vue3為什么要推倒重來Vue2的響應(yīng)式是基于Object.defineProperty實(shí)現(xiàn)的。這個(gè)API能攔截屬性的讀取和寫入但有幾個(gè)繞不開的硬傷對象新增屬性不會觸發(fā)視圖更新刪除屬性也不會數(shù)組的索引賦值和length變化只能通過重寫數(shù)組方法的方式做部分補(bǔ)救。所以Vue2里不得不提供Vue.set和Vue.delete這些額外API來處理邊界場景組件里到處都是this.$set寫起來不優(yōu)雅漏寫就出bug。Vue3整個(gè)換成了Proxy。Proxy代理的是整個(gè)對象而不是某個(gè)屬性因此新增屬性、刪除屬性天然能被攔截?cái)?shù)組索引和length也不再需要hack。更關(guān)鍵的是Vue3把響應(yīng)式能力拆成了reactive、ref、computed、watchEffect等獨(dú)立的API不依賴組件實(shí)例才能收集依賴。Vue2里依賴收集是綁定在組件Watcher上的到了Vue3變成了一個(gè)底層通用的effect機(jī)制組件更新只是其中一種effect。這個(gè)設(shè)計(jì)讓響應(yīng)式系統(tǒng)可以脫離組件獨(dú)立存在也為Tree-Shaking、TypeScript類型推導(dǎo)鋪好了路。我記得第一次看Vue3源碼時(shí)最大的感受是它是把響應(yīng)式當(dāng)成了一個(gè)完全可以獨(dú)立運(yùn)行的模塊來設(shè)計(jì)的而不是組件框架的附屬品。理解了這一點(diǎn)再看reactive和ref的設(shè)計(jì)很多困惑都會迎刃而解。1.2 核心設(shè)計(jì)目標(biāo)依賴收集與觸發(fā)更新整個(gè)響應(yīng)式系統(tǒng)可以用一句話概括讀取數(shù)據(jù)時(shí)收集依賴修改數(shù)據(jù)時(shí)觸發(fā)依賴。聽起來簡單但拆開之后里面有幾個(gè)關(guān)鍵問題需要解決如何知道當(dāng)前正在讀取數(shù)據(jù)的代碼是誰如何把數(shù)據(jù)變化和依賴建立映射關(guān)系如何在數(shù)據(jù)變化時(shí)精準(zhǔn)找到所有相關(guān)依賴并執(zhí)行它們?nèi)绾伪苊庵貜?fù)收集、如何處理嵌套effect、如何防止無限循環(huán)Vue3的答案是一套三層數(shù)據(jù)結(jié)構(gòu)WeakMap目標(biāo)對象, Map屬性名, Set副作用函數(shù)。最外層用WeakMapkey是目標(biāo)對象value是對應(yīng)于這個(gè)對象上所有屬性的依賴映射中間層是Mapkey是屬性名最里層是Set存放該屬性關(guān)聯(lián)的所有effect副作用函數(shù)。選擇WeakMap而不是Map原因很巧妙WeakMap的key是弱引用當(dāng)目標(biāo)對象本身不再被任何地方引用時(shí)它對應(yīng)的整個(gè)依賴映射就能被垃圾回收不會造成內(nèi)存泄漏。如果你用普通的Map被響應(yīng)式包裝過的對象即使業(yè)務(wù)上已經(jīng)不需要了依賴映射還掛在Map上內(nèi)存就泄漏了。這一點(diǎn)在長頁面、大數(shù)據(jù)列表的場景下非常關(guān)鍵。中間層用Map而不是直接把Set掛在對象上是因?yàn)橹苯訏燧d會修改對象自身又會觸發(fā)響應(yīng)式攔截形成死循環(huán)而且Map按key定位屬性的性能也比遍歷好得多。2. 核心機(jī)制Proxy與Reflect的配合2.1 Proxy攔截能力全面解析Proxy可以攔截13種底層操作Vue3的響應(yīng)式系統(tǒng)中主要用到了其中5種get、set、has、deleteProperty、ownKeys。get在讀取屬性時(shí)觸發(fā)是依賴收集的主戰(zhàn)場。set在修改屬性時(shí)觸發(fā)是觸發(fā)更新的主戰(zhàn)場。has在in操作符檢查屬性是否存在時(shí)觸發(fā)deleteProperty在delete obj.xxx時(shí)觸發(fā)ownKeys在Object.keys、for...in等遍歷操作時(shí)觸發(fā)。后三者解決的是Vue2完全做不到的屬性是否存在這個(gè)維度的問題。看一個(gè)簡化但完整的手寫reactive核心const targetMap new WeakMap() let activeEffect null function track(target, key) { if (!activeEffect) return let depsMap targetMap.get(target) if (!depsMap) { targetMap.set(target, (depsMap new Map())) } let dep depsMap.get(key) if (!dep) { depsMap.set(key, (dep new Set())) } // 把當(dāng)前激活的effect加入dep同時(shí)反向記錄dep方便清空 dep.add(activeEffect) activeEffect.deps.push(dep) } function trigger(target, key) { const depsMap targetMap.get(target) if (!depsMap) return const dep depsMap.get(key) if (dep) { dep.forEach(effect effect()) } }這只是最樸素的骨架真實(shí)源碼里還得處理迭代key、新舊值判斷、effect的scheduler調(diào)度等但主干思路就是這樣。先理解這個(gè)再往源碼深處走就不迷路。2.2 為什么必須用Reflect只寫return target[key]行不行大多數(shù)時(shí)候行但遇到訪問器屬性和繼承場景就會出問題。看這個(gè)例子const obj { _value: 1, get value() { // this指向誰直接決定能不能拿到響應(yīng)式屬性 return this._value } }如果用new Proxy(obj, { get(target, key) { return target[key] } })來包裝當(dāng)通過代理對象訪問value時(shí)getter里的this指向的是target原始對象而不是代理對象。如果_value在原始對象上沒有響應(yīng)式包裝this._value取到的就是普通值。一旦對象存在繼承關(guān)系子類實(shí)例通過繼承的getter訪問自身屬性時(shí)這個(gè)this指向問題就更加致命。Reflect.get(target, key, receiver)的第三個(gè)參數(shù)receiver就是來解決這個(gè)問題的。它讓getter里的this指向receiver也就是代理對象本身從而保證整個(gè)鏈路都在響應(yīng)式系統(tǒng)的掌控之中。Vue3源碼里對get、set、deleteProperty、has全部使用Reflect對應(yīng)方法并不是為了炫技而是確保代理對象在語義上和原始對象完全一致。這一點(diǎn)很多手寫響應(yīng)式的教程不會講但往往是生產(chǎn)環(huán)境詭異bug的根源。2.3 特殊對象與標(biāo)記位處理reactive只處理對象對原始類型值無能為力所以Vue3才嗎要設(shè)計(jì)ref來兜底。此外reactive還有一些內(nèi)置的特殊處理對Date、RegExp、Map、Set、WeakMap、WeakSet這些內(nèi)置對象會走專門的collectionHandlers去攔截因?yàn)樗鼈兊淖x取和修改多數(shù)是通過方法調(diào)用而不是屬性訪問。對帶有__v_skip標(biāo)記的對象直接跳過對只讀對象也有單獨(dú)的readonlyHandlers。我用實(shí)際開發(fā)中的例子來說如果你在reactive對象里塞了一個(gè)Set然后直接set.add(item)這個(gè)操作默認(rèn)是不會觸發(fā)更新的必須通過Vue3重寫過的一層方法調(diào)用才能被捕獲。之所以能做到就是因?yàn)樵趃et攔截時(shí)如果發(fā)現(xiàn)目標(biāo)對象是內(nèi)置集合類型會返回一個(gè)包裝過的add、delete等方法這些方法內(nèi)部先執(zhí)行原始操作再手動調(diào)用trigger。這個(gè)機(jī)制平時(shí)不太會被注意到但一旦碰到Set里加了數(shù)據(jù)視圖死活不更新的問題排查方向就對了。3. 依賴收集與派發(fā)更新的完整邏輯3.1 track的完整實(shí)現(xiàn)與細(xì)節(jié)真實(shí)源碼里的track沒有我上面寫的那么簡略它需要處理不同操作類型并且只關(guān)心那些可能被追蹤的key。比如ITERATE_KEY這個(gè)特殊key用來代表for...in和Object.keys這類遍歷操作。當(dāng)對象新增或刪除屬性時(shí)不僅要找到對應(yīng)屬性的dep還要找到ITERATE_KEY的dep一起觸發(fā)。這就是為什么set攔截在新增屬性和修改已有屬性時(shí)的處理邏輯不一樣新增屬性要額外觸發(fā)迭代依賴因?yàn)楸闅v集合的成員數(shù)變多了。還有一點(diǎn)容易被忽略track里每個(gè)effect會維護(hù)一個(gè)deps數(shù)組作用是在effect重新執(zhí)行前先把上一次收集到的依賴全部清空再重新收集。這個(gè)過程叫分支切換。假設(shè)某個(gè)條件的值導(dǎo)致effect讀不到了某個(gè)屬性不去清理的話下次觸發(fā)這個(gè)屬性時(shí)還會執(zhí)行這個(gè)effect造成無意義的re-run。Vue3用了一個(gè)cleanupEffect的過程遍歷effect的deps數(shù)組把effect從每個(gè)dep里刪掉然后把deps數(shù)組置空再重新跑一次effect重新收集依賴。3.2 trigger的完整實(shí)現(xiàn)與調(diào)度機(jī)制trigger要處理的核心問題有兩個(gè)一是精準(zhǔn)找到應(yīng)該被觸發(fā)的effect二是控制effect執(zhí)行的時(shí)機(jī)和方式。第一點(diǎn)通過targetMap就能定位到具體dep。但set操作還要區(qū)分是修改已有屬性還是新增屬性新增和刪除都要額外觸發(fā)ITERATE_KEY的依賴。還有一個(gè)細(xì)節(jié)是如果對象是一個(gè)通過ref包裝后暴露出來的對象觸發(fā)方式會不太一樣因?yàn)閞ef的value屬性本身就是一個(gè)key。第二點(diǎn)涉及effect的options。Vue3的trigger在執(zhí)行依賴時(shí)不會直接無腦調(diào)用它會先判斷effect是否帶有computed標(biāo)志如果當(dāng)前正在執(zhí)行的effect和即將觸發(fā)的effect有依賴關(guān)系比如computed在更新過程中又觸發(fā)自己的依賴需要通過id大小關(guān)系決定是否跳過避免循環(huán)更新。還會檢查effect是否帶scheduler如果帶了就把schedule執(zhí)行機(jī)會交給調(diào)度器而不是直接執(zhí)行effect本身。watchEffect的異步批量執(zhí)行就是依靠scheduler配合Promise微任務(wù)隊(duì)列實(shí)現(xiàn)的。簡單理解scheduler就是先排隊(duì)、再執(zhí)行的調(diào)度入口。普通effect直接跑帶watch的effect會把更新任務(wù)放進(jìn)一個(gè)隊(duì)列等當(dāng)前同步代碼執(zhí)行完后統(tǒng)一flush這樣多次修改數(shù)據(jù)只會觸發(fā)一次視圖更新性能收益在復(fù)雜組件里非常明顯。3.3 activeEffect棧解決嵌套effect的依賴歸屬什么是嵌套effect最常見的就是computed內(nèi)部訪問了響應(yīng)式數(shù)據(jù)而computed又在另一個(gè)effect比如組件渲染中被讀取。此時(shí)computed內(nèi)部的讀取操作依賴應(yīng)該收集到誰身上如果只用單一的activeEffect變量內(nèi)層computed執(zhí)行時(shí)會把外層effect頂?shù)舻萩omputed跑完外層effect的激活狀態(tài)就丟了之后的依賴收集就全亂套了。Vue3的解法是用一個(gè)棧activeEffectStack。effect開始執(zhí)行前把自身push進(jìn)棧執(zhí)行結(jié)束后pop出來activeEffect始終取棧頂元素。這樣嵌套結(jié)構(gòu)就能正確地讓內(nèi)層讀取收集到內(nèi)層effect外層讀取收集到外層effect。我在看源碼前一直不理解為什么源碼里到處是activeEffect ! undefined這種判斷看了這個(gè)棧的設(shè)計(jì)才明白它是一個(gè)執(zhí)行上下文的標(biāo)記和函數(shù)調(diào)用棧是同一個(gè)思路。4. reactive、ref與computed的源碼實(shí)現(xiàn)4.1 reactive從Proxy到緩存復(fù)用reactive的入口其實(shí)非常簡潔new Proxy(target, baseHandlers)其中baseHandlers就是前面說的那組攔截器。但有一個(gè)隱藏設(shè)計(jì)同一個(gè)原始對象多次調(diào)用reactive()必須返回同一個(gè)代理對象。Vue3用一個(gè)reactiveMapWeakMap記錄了原始對象到代理對象的映射。第一次包裝后存入map后續(xù)再調(diào)用直接return緩存結(jié)果。這個(gè)緩存機(jī)制除了性能考量更關(guān)鍵的是保證同一個(gè)對象在整個(gè)應(yīng)用中只有一個(gè)代理身份這樣依賴收集才不會重復(fù)。baseHandlers的get攔截中還有一層isReadonly判斷但核心邏輯是拿到原始值后如果是對象就遞歸調(diào)用reactive繼續(xù)深層包裝對耗時(shí)操作Vue3還做了緩存——同一個(gè)key多次讀取時(shí)返回的綁定函數(shù)不會重復(fù)創(chuàng)建。源碼中的cache屬性就是干這個(gè)的。還有個(gè)容易被忽略的現(xiàn)象reactive包裝后得到的代理對象再被reactive一次會直接返回同一個(gè)代理。這個(gè)行為底層就是靠reactiveMap查緩存實(shí)現(xiàn)的。4.2 ref為什么需要一個(gè).valueref解決的是reactive無法處理基本類型的問題。它的核心實(shí)現(xiàn)是一個(gè)類內(nèi)部用一個(gè)_value存值通過訪問器屬性value暴露讀寫。class RefImpl { constructor(value) { this._value toReactive(value) // 對象值的化內(nèi)部用reactive包裝 this.__v_isRef true } get value() { track(this, value) return this._value } set value(newVal) { this._value toReactive(newVal) trigger(this, value) } }讀.value時(shí)track寫.value時(shí)trigger因?yàn)閞ef實(shí)例本身是個(gè)對象targetMap的key就是ref實(shí)例。設(shè)計(jì)中值得注意的點(diǎn)是toReactive如果傳入ref的值是個(gè)對象它內(nèi)部會用reactive再包裝一層。所以ref({})和reactive({})在深層對象上是殊途同歸的只是ref多了一層.value的外殼。模板里的自動解包、toRefs、isRef這些API本質(zhì)都是圍繞這個(gè).value設(shè)計(jì)展開的。模板自動解包其實(shí)就是渲染過程中對讀取的屬性做了一次isRef判斷是ref的話就直接取.value用戶不需要在模板里手動寫.value。4.3 computed惰性求值與緩存computed是基于effect實(shí)現(xiàn)的但它有一個(gè)dirty標(biāo)記來控制緩存。第一次讀取computed的值時(shí)dirty為true執(zhí)行內(nèi)部函數(shù)計(jì)算并緩存結(jié)果然后設(shè)置dirty為false。之后只要依賴的數(shù)據(jù)沒變每次讀取都直接返回緩存值不會重復(fù)計(jì)算。當(dāng)依賴的數(shù)據(jù)被修改觸發(fā)內(nèi)部的scheduler把dirty置回true但此時(shí)不立即計(jì)算等到下一次computed.value被讀取時(shí)才重新計(jì)算。這就是惰性求值。這個(gè)機(jī)制在復(fù)雜計(jì)算場景下收益極大。比如一個(gè)computed遍歷幾千條數(shù)據(jù)做過濾只要依賴數(shù)組沒變哪怕被模板讀取一百次也只會計(jì)算一次。如果換成一個(gè)watchEffect每次依賴變化都會立刻執(zhí)行計(jì)算開銷完全不同。computed還有一個(gè)特殊點(diǎn)它自己也是一個(gè)effect當(dāng)它內(nèi)部訪問其他響應(yīng)式數(shù)據(jù)時(shí)會作為依賴收集進(jìn)去當(dāng)它被外層effect讀取時(shí)又會把自己的計(jì)算結(jié)果貢獻(xiàn)出去。嵌套關(guān)系就是靠這個(gè)鏈條建立的。5. 驅(qū)動視圖更新與異步調(diào)度細(xì)節(jié)講到這里很多人會產(chǎn)生一個(gè)疑問數(shù)據(jù)變了trigger執(zhí)行了effect但effect怎么知道要更新組件、更新DOM這就要看componentUpdateFn了。Vue3的組件渲染其實(shí)也是一個(gè)effect它包著一層render函數(shù)render里會讀取模板用到的響應(yīng)式數(shù)據(jù)從而觸發(fā)track數(shù)據(jù)變化時(shí)trigger觸發(fā)這個(gè)渲染effect重新執(zhí)行render。但這里有個(gè)重要的調(diào)度機(jī)制組件更新不是同步立即執(zhí)行的。Vue3把渲染effect的trigger放在了一個(gè)scheduler里更新請求會被推入一個(gè)隊(duì)列再通過nextTick或者微任務(wù)批量flush。所以你在一次同步操作里連續(xù)改三次數(shù)據(jù)最終只會觸發(fā)一次組件更新。這也是為什么watch回調(diào)里拿到的DOM不一定是最終狀態(tài)要操作更新后的DOM必須等到nextTick。生產(chǎn)環(huán)境里這個(gè)調(diào)度機(jī)制帶來的最典型體驗(yàn)是大量數(shù)據(jù)在極短時(shí)間內(nèi)的連續(xù)變化不會導(dǎo)致渲染層反復(fù)震蕩。比如你在一個(gè)for循環(huán)里改了100次某個(gè)reactive數(shù)組整個(gè)過程只會觸發(fā)一次重渲染。queueJob的執(zhí)行還有一個(gè)優(yōu)先級細(xì)節(jié)Vue3會給不同任務(wù)的job分配id在下一輪微任務(wù)中按id從小到大執(zhí)行確保父子組件之間更新的順序是合理的避免一個(gè)組件在更新時(shí)讀到尚未更新的子組件狀態(tài)。6. 實(shí)際項(xiàng)目中的坑與排查技巧實(shí)錄6.1 解構(gòu)丟失響應(yīng)性這個(gè)坑面試必問項(xiàng)目里也是重災(zāi)區(qū)。直接看代碼const state reactive({ count: 1, name: vue3 }) // 解構(gòu)之后count就是普通數(shù)字不再響應(yīng)式 const { count } state state.count 2 // 視圖不會更新原因還不明顯的話可以往下看一眼解構(gòu)拿到的count只是一個(gè)普通值快照它和state.count這個(gè)屬性之間并沒有維持關(guān)系。解決方案是用toRefsconst { count, name } toRefs(state) // 此時(shí)count是一個(gè)refcount.value始終與state.count保持同步toRefs內(nèi)部其實(shí)就是把每個(gè)key包裝成一個(gè)ObjectRefImpl該類的value訪問器里get時(shí)讀取原始對象對應(yīng)key的值set時(shí)寫回。這樣解構(gòu)出來的每個(gè)值都還是響應(yīng)式的。我在項(xiàng)目里統(tǒng)一規(guī)定從reactive對象上解構(gòu)屬性一律用toRefs包一層從根上杜絕這類問題。6.2 數(shù)組索引與length的觸發(fā)范圍Proxy雖然能攔截?cái)?shù)組索引賦值但Vue3對數(shù)組的響應(yīng)式處理有細(xì)致邊界。直接用arr[10] 1這種方式給一個(gè)length為5的數(shù)組新增一個(gè)下標(biāo)會觸發(fā)Index類型操作并且觸發(fā)的依賴key是10但同時(shí)length的變化不會觸發(fā)length這個(gè)key的依賴。如果你的界面是依賴arr.length來展示數(shù)量的數(shù)字不會同步變。規(guī)范的做法是要么直接改arr.length 11這會觸發(fā)length依賴要么用push、splice這些會同步更新length的數(shù)組方法。我自己排查過類似問題界面顯示的列表?xiàng)l數(shù)是基于computed(() list.value.length)寫的但動態(tài)在下標(biāo)上賦值導(dǎo)致列表內(nèi)容變了總條數(shù)紋絲不動。6.3 shallowRef與triggerRef性能優(yōu)化和強(qiáng)制刷新shallowRef只對.value本身做響應(yīng)式.value指向的對象的深層屬性變化不會被追蹤。比如const info shallowRef({ name: vue3, version: 3 }) info.value.name Vue3.4 // 不觸發(fā)更新但如果你確切知道對象已經(jīng)變了只是想手動通知視圖刷新可以用triggerRef(info)強(qiáng)制觸發(fā)。源碼里triggerRef就是繞開依賴檢查直接對該ref做一次trigger操作。這個(gè)API在優(yōu)化超大對象、第三方原生對象比如ECharts實(shí)例時(shí)很好用但日常業(yè)務(wù)代碼不建議頻繁使用它本質(zhì)上把自動檢測降級成了手動通知。6.4 reactive對象直接操作Map/Set的問題前面提過reactive包裝的Map和Set需要在get攔截時(shí)返回包裝方法才能觸發(fā)更新。實(shí)際編碼中最常見的錯(cuò)法是state.map.set(key, value)之后界面不更新。這是因?yàn)閟tate.map拿到的已經(jīng)是被攔截過的代理方法但如果這個(gè)Map是在reactive外部創(chuàng)建的而你又把原始Map塞進(jìn)了reactive對象后續(xù)直接用原始Map的set方法就錯(cuò)過了攔截層。排查這類問題的萬能手段是在trigger函數(shù)源碼里打斷點(diǎn)或者給effect重新執(zhí)行加log看看數(shù)據(jù)變化到底有沒有走到派發(fā)鏈路。我在內(nèi)網(wǎng)排障時(shí)常用Chrome的Sources面板直接在trigger的實(shí)現(xiàn)位置打條件斷點(diǎn)條件設(shè)成target的key名數(shù)據(jù)變化后走到這里就停住然后逐步看dep集合里有沒有預(yù)期effect。這套方法比盲目console.log高效得多。6.5 依賴收集與內(nèi)存泄漏的常見誤解有些同學(xué)擔(dān)心WeakMap只對target弱引用是不是意味著多次創(chuàng)建reactive(obj)會讓舊的代理對象無法清理其實(shí)不會因?yàn)閞eactiveMap本身持有target到proxy的強(qiáng)引用target在業(yè)務(wù)中如果沒有被釋放proxy也會一直被緩存。反過來如果target已經(jīng)沒有任何引用reactiveMap里的條目就會被GC自動回收proxy自然也就沒有持有者了。這個(gè)設(shè)計(jì)是深思熟慮的。但需要注意一個(gè)實(shí)踐場景當(dāng)一個(gè)對象不再需要響應(yīng)式時(shí)單純的delete obj.xxx只會觸發(fā)更新不會自動從targetMap里移除依賴映射。真正要釋放響應(yīng)式關(guān)系只能讓對象本身失去引用。如果業(yè)務(wù)上有長生命周期對象動態(tài)注冊到reactive容器的需求最好及時(shí)清理容器中的引用否則依賴會越積越多。雖然響應(yīng)式系統(tǒng)本身不會泄漏但業(yè)務(wù)層不清理引用GC照樣無能為力。最后分享兩個(gè)調(diào)試技巧排查響應(yīng)式問題時(shí)我個(gè)人的習(xí)慣是第一眼先判斷數(shù)據(jù)是基本類型還是對象類型分別對應(yīng)ref和reactive兩條排查路徑再判斷是沒收集到依賴還是觸發(fā)了但沒反映到視圖。前者去track里看dep集合后者去effect的調(diào)度隊(duì)列里看job是否正常執(zhí)行。還有一個(gè)對我?guī)椭艽蟮募记稍诮M件setup里臨時(shí)掛一個(gè)全局變量比如window.__state state然后直接在控制臺里對state賦值觀察頁面是否實(shí)時(shí)更新。這樣一來就能快速區(qū)分?jǐn)?shù)據(jù)真的沒變還是響應(yīng)式鏈路斷了。控制臺里看到的reactive對象值變化時(shí)你會看到它顯示為Proxy包裹狀態(tài)這一點(diǎn)本身也能幫你確認(rèn)對象到底有沒有被正確包裝。響應(yīng)式系統(tǒng)并不神秘核心就是讀時(shí)收集、寫時(shí)觸發(fā)這八個(gè)字。理解了track、trigger、effect這三者的閉環(huán)再看Vue3的其他API你會發(fā)現(xiàn)它們都是在基本盤上做的封裝和優(yōu)化。希望這篇文章能讓你在遇到響應(yīng)式問題時(shí)少一些猜測多一些底氣。