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