Vuex 這玩意兒現(xiàn)在提起來(lái)有點(diǎn)微妙。新項(xiàng)目里 Pinia 基本是默認(rèn)選項(xiàng)很多人一上手 Vue 3 就沒(méi)碰過(guò) Vuex。但你去翻一翻手上維護(hù)的那些跑了三四年的中后臺(tái)系統(tǒng)十有八九還在store/index.js里躺著幾十個(gè) mutation改一個(gè)字段要先找 action、再找 mutation、最后才敢動(dòng) state。這時(shí)候你要是連 Vuex 的執(zhí)行鏈路都說(shuō)不清楚排查問(wèn)題基本靠猜。這篇就把 Vuex 的知識(shí)點(diǎn)掰開揉碎講透從“到底什么時(shí)候該用它”到“store 怎么拆模塊”再到“為什么我的 commit 沒(méi)生效”這類真實(shí)踩坑全部過(guò)一遍。適合兩類人看一類是剛接手老項(xiàng)目、被mapState和各種root: true繞暈的新手另一類是想把狀態(tài)管理這塊徹底搞清楚、以后不管換 Pinia 還是別的庫(kù)都能快速上手的同學(xué)。代碼以 Vuex 4 Vue 3 為主線涉及 Vue 2 的差異我會(huì)單獨(dú)標(biāo)出來(lái)。1. 先搞清楚什么時(shí)候真的需要 Vuex1.1 狀態(tài)管理的邊界到底在哪我在帶人的時(shí)候發(fā)現(xiàn)一個(gè)特別普遍的問(wèn)題很多人學(xué)完 Vuex 的第一反應(yīng)是“好東西全塞進(jìn)去”。結(jié)果一個(gè)只有三個(gè)頁(yè)面的小工具store 里堆了二十多個(gè)字段其中一半是某個(gè)組件內(nèi)部的彈窗開關(guān)。這就屬于把狀態(tài)管理當(dāng)成了全局變量倉(cāng)庫(kù)最后維護(hù)成本比不用還高。判斷一個(gè)狀態(tài)該不該進(jìn) store我一般看三條第一這份數(shù)據(jù)是不是被兩個(gè)以上互不相鄰的組件同時(shí)使用。父子組件之間傳值props加emit就夠了爺孫層級(jí)深一點(diǎn)provide/inject也能解決。只有當(dāng)兄弟組件、或者跨了好幾層的遠(yuǎn)房親戚都要讀寫同一份數(shù)據(jù)時(shí)才輪到 Vuex 出場(chǎng)。第二這份數(shù)據(jù)是不是跨越了路由。比如登錄態(tài)、用戶信息、權(quán)限菜單從 A 頁(yè)面跳到 B 頁(yè)面還得用這種放在組件里必然會(huì)隨著組件銷毀而丟失必須提上去。第三這份數(shù)據(jù)變更后是不是需要留下可追溯的痕跡。Vuex 配 devtools 能記錄每一次 mutation 的時(shí)間旅行對(duì)于復(fù)雜的表單聯(lián)動(dòng)、購(gòu)物車增刪改這個(gè)調(diào)試能力值不少時(shí)間。反過(guò)來(lái)說(shuō)哪些不該進(jìn) store組件的 loading 狀態(tài)、某個(gè)列表的滾動(dòng)位置、彈窗的顯隱開關(guān)這些都屬于“局部狀態(tài)”跟著組件生命周期走才是最干凈的。我見過(guò)有人把dialogVisible放進(jìn) store結(jié)果兩個(gè)頁(yè)面復(fù)用同一個(gè)彈窗組件時(shí)互相干擾排查了半天才發(fā)現(xiàn)是狀態(tài)被共享了。記住一句話狀態(tài)放得越高耦合就越重能不升就不升。還有一種常見誤區(qū)是把接口返回的原始數(shù)據(jù)全量塞進(jìn) store然后組件里再filter一遍。這樣做的問(wèn)題在于 store 變成了緩存層但你又沒(méi)做失效策略最后數(shù)據(jù)新舊不一致的 bug 特別難查。我的習(xí)慣是 store 只存“經(jīng)過(guò)業(yè)務(wù)加工、有明確語(yǔ)義”的狀態(tài)原始響應(yīng)體在 action 里處理完就丟掉。1.2 Vuex 和 Pinia 到底怎么選這個(gè)話題繞不開。Pinia 確實(shí)是官方現(xiàn)在主推的方案API 更簡(jiǎn)潔、TypeScript 支持更好、沒(méi)有 mutation 這一層。但“新項(xiàng)目用 Pinia”不等于“Vuex 就沒(méi)用了”。我整理了一張對(duì)照表你對(duì)著自己項(xiàng)目的情況看就行。對(duì)比維度Vuex 4Pinia變更入口mutation 提交action 觸發(fā)直接改 stateaction 里也能改模塊機(jī)制modules namespaced 嵌套每個(gè) store 天然獨(dú)立TypeScript 支持需要額外類型聲明較繁瑣原生推導(dǎo)幾乎零配置devtools 時(shí)間旅行支持粒度到 mutation支持粒度到 action代碼量一個(gè)功能要寫 state/getter/mutation/action 四份基本一份 setup 或 option 就夠?qū)W習(xí)曲線概念多鏈路長(zhǎng)概念少接近組合式函數(shù)存量項(xiàng)目兼容原生可與 Vuex 共存逐模塊遷移適合場(chǎng)景老項(xiàng)目維護(hù)、團(tuán)隊(duì)已有約定新項(xiàng)目、TS 重度使用我的實(shí)際經(jīng)驗(yàn)是已經(jīng)在跑的 Vuex 項(xiàng)目別為了追新去動(dòng)它。遷移本身不難難的是遷移期間兩套狀態(tài)管理并存帶來(lái)的心智負(fù)擔(dān)以及測(cè)試覆蓋不足時(shí)的回歸風(fēng)險(xiǎn)。真要遷也是按模塊一個(gè)個(gè)搬先把用戶模塊搬過(guò)去跑一周沒(méi)問(wèn)題再搬下一個(gè)。反倒是新起的項(xiàng)目沒(méi)有歷史包袱直接上 Pinia 更省事。不過(guò)有一點(diǎn)要說(shuō)清楚Vuex 那套“mutation 必須同步、action 處理異步”的約束雖然寫起來(lái)啰嗦但它強(qiáng)迫你把“改數(shù)據(jù)”和“做業(yè)務(wù)”分開這個(gè)思維在團(tuán)隊(duì)協(xié)作里是有價(jià)值的。很多 Pinia 新手直接在 action 里一頓this.xxx yyy出了問(wèn)題連是哪一步改的都定位不到。所以就算你用的是 Pinia也建議保留“純函數(shù)式改狀態(tài)”的習(xí)慣。1.3 一張判斷清單幫你決定要不要引入我給自己團(tuán)隊(duì)寫過(guò)一個(gè)很土但很好用的清單五個(gè)問(wèn)題中三個(gè)以上才考慮上 Vuex有沒(méi)有一份數(shù)據(jù)被三個(gè)以上的組件讀取且這些組件不在同一條父子鏈上這份數(shù)據(jù)會(huì)不會(huì)因?yàn)槁酚汕袚Q而需要保留這份數(shù)據(jù)的修改是否需要多人協(xié)作、且改動(dòng)點(diǎn)分散在多個(gè)文件出問(wèn)題時(shí)是否需要回放“誰(shuí)在什么時(shí)候改了什么”項(xiàng)目規(guī)模是不是已經(jīng)超過(guò)二十個(gè)頁(yè)面或者五個(gè)以上的業(yè)務(wù)模塊如果只中一兩條老老實(shí)實(shí)用props加組合式函數(shù)封裝別給自己找事。狀態(tài)管理的本質(zhì)是降低溝通成本不是炫技。2. Vuex 的五個(gè)核心概念一次捋直2.1 state單一狀態(tài)樹和它的設(shè)計(jì)原則Vuex 把所有狀態(tài)收攏到一棵樹里官方叫單一狀態(tài)樹Single Source of Truth。好處是任何一個(gè)時(shí)刻你都能通過(guò)store.state拿到應(yīng)用完整的數(shù)據(jù)快照調(diào)試的時(shí)候特別直觀。壞處是這棵樹如果沒(méi)人管長(zhǎng)到幾百個(gè)字段之后新人進(jìn)來(lái)根本看不懂哪個(gè)字段屬于哪個(gè)業(yè)務(wù)。我的做法是按業(yè)務(wù)域切分而不是按數(shù)據(jù)類型切分。什么叫按數(shù)據(jù)類型切就是state.list、state.detail、state.loading這么平鋪看著整齊實(shí)際上一旦業(yè)務(wù)變多就全亂。按業(yè)務(wù)域切就是user、order、permission各占一塊每個(gè)模塊自洽。具體到寫法Vuex 4 里定義模塊的 state 一定要用函數(shù)返回對(duì)象// store/modules/user.js const state () ({ profile: null, token: , roles: [], permissionLoaded: false })為什么必須是函數(shù)因?yàn)槟K在注冊(cè)時(shí)會(huì)被合并進(jìn)根 state如果直接寫對(duì)象字面量多個(gè)組件實(shí)例或者熱更新場(chǎng)景下會(huì)共享同一份引用出現(xiàn)“A 頁(yè)面改了 B 頁(yè)面也變了”的靈異事件。這個(gè)坑我在服務(wù)端渲染的項(xiàng)目里踩過(guò)一次排查了整整一個(gè)下午。另外 state 里的字段命名要帶語(yǔ)義。data、info、list這種詞盡量別用orderList、userProfile、pendingTaskCount一眼就知道是什么。字段一多命名就是最好的文檔。2.2 getters派生狀態(tài)和它的緩存機(jī)制getters 可以理解為 store 里的 computed。它的返回值會(huì)基于依賴做緩存依賴不變就不重新計(jì)算。這個(gè)特性用好了能省不少性能用不好反而會(huì)成為 bug 來(lái)源。const getters { isLogin: state Boolean(state.token), displayName: state state.profile?.nickname || state.profile?.username || 未登錄, // 依賴其他 getter第二個(gè)參數(shù)是當(dāng)前模塊的 getters welcomeText: (state, getters) ${getters.displayName}歡迎回來(lái), // 依賴根 state第四個(gè)參數(shù)是 rootState hasPermission: (state, getters, rootState) code { return state.roles.includes(code) || rootState.user.roles.includes(code) } }這里有個(gè)關(guān)鍵點(diǎn)getter 返回函數(shù)時(shí)緩存就失效了。上面hasPermission返回的是一個(gè)函數(shù)每次調(diào)用都會(huì)重新執(zhí)行因?yàn)?Vue 沒(méi)法追蹤函數(shù)內(nèi)部用到的參數(shù)。這種寫法適合做權(quán)限判斷這類需要傳參的場(chǎng)景但別在模板里高頻調(diào)用它尤其是列表渲染里v-for每一項(xiàng)都調(diào)一次性能會(huì)明顯下降。真要這么用先在 computed 里把結(jié)果算好。還有一個(gè)容易翻車的地方getter 里返回新對(duì)象。比如// 不推薦每次都返回新數(shù)組緩存形同虛設(shè) filteredList: state state.list.filter(item item.active)因?yàn)閒ilter每次執(zhí)行都會(huì)產(chǎn)生新數(shù)組引用Vue 的依賴追蹤會(huì)認(rèn)為結(jié)果變了導(dǎo)致依賴這個(gè) getter 的組件反復(fù)更新。如果這個(gè)列表很大、更新又頻繁頁(yè)面會(huì)明顯卡頓。正確做法是把過(guò)濾邏輯放到組件 computed 里或者用shallowRef之類的思路做手動(dòng)緩存。我在一個(gè)萬(wàn)級(jí)數(shù)據(jù)的表格項(xiàng)目里就吃過(guò)這個(gè)虧后來(lái)把 getter 改成了只做簡(jiǎn)單映射流暢度立刻回來(lái)了。2.3 mutations為什么它必須是同步的這是 Vuex 里被問(wèn)得最多的問(wèn)題?！拔揖驮?mutation 里發(fā)個(gè)請(qǐng)求怎么了”答案藏在 devtools 的工作原理里。devtools 記錄狀態(tài)變化的方式是每執(zhí)行一次 mutation就拍一張 state 的快照存進(jìn)時(shí)間線。如果你在 mutation 里發(fā)異步請(qǐng)求那么“mutation 開始執(zhí)行”和“state 真正被改”之間存在時(shí)間差devtools 拍到的那張快照可能是請(qǐng)求還沒(méi)回來(lái)的中間態(tài)。等你點(diǎn)時(shí)間旅行回到某一步看到的狀態(tài)和實(shí)際不符調(diào)試就徹底失去了意義。所以 Vuex 強(qiáng)制 mutation 同步是為了保證每一幀快照都是確定性的。const mutations { SET_PROFILE(state, payload) { state.profile payload }, SET_TOKEN(state, token) { state.token token }, ADD_ROLE(state, role) { if (!state.roles.includes(role)) { state.roles.push(role) } }, RESET(state) { // 重置時(shí)不要直接替換整個(gè) state 對(duì)象Vue 會(huì)丟失響應(yīng)式追蹤 Object.assign(state, { profile: null, token: , roles: [], permissionLoaded: false }) } }mutation 的命名我統(tǒng)一用全大寫加下劃線這是社區(qū)慣例好處是在 devtools 列表里一眼就能和 action 區(qū)分開。action 用小駝峰比如fetchProfile。這套約定看起來(lái)是小事但團(tuán)隊(duì)人多的時(shí)候能省掉很多溝通。還有一個(gè)細(xì)節(jié)mutation 里不要做副作用。什么叫副作用發(fā)請(qǐng)求、寫 localStorage、彈 toast這些都算。mutation 應(yīng)該是一個(gè)純函數(shù)給它同樣的輸入state 就變成同樣的結(jié)果。這樣你寫單元測(cè)試的時(shí)候只需要斷言 state 變化不用 mock 一堆東西。2.4 actions異步編排和業(yè)務(wù)邏輯的落腳點(diǎn)action 是 Vuex 里唯一允許寫異步的地方它不直接改 state而是通過(guò)commit觸發(fā) mutation。這個(gè)設(shè)計(jì)看起來(lái)多繞了一層實(shí)際上把“業(yè)務(wù)流程”和“數(shù)據(jù)變更”解耦了。const actions { async fetchProfile({ commit, state, dispatch }, force false) { if (state.profile !force) { return state.profile } const res await api.getUserProfile() commit(SET_PROFILE, res.data) // 跨模塊調(diào)用要加 root: true await dispatch(permission/loadRoutes, res.data.roles, { root: true }) return res.data }, async login({ commit, dispatch }, { username, password }) { const { token } await api.login({ username, password }) commit(SET_TOKEN, token) await dispatch(fetchProfile, true) }, logout({ commit }) { commit(RESET) commit(permission/RESET, null, { root: true }) } }action 的返回值很重要。因?yàn)?action 內(nèi)部是 Promise你可以在組件里await store.dispatch(login, form)拿到結(jié)果后再做跳轉(zhuǎn)或者提示。很多老代碼里 action 不 return組件只能靠 watch 某個(gè) state 來(lái)判斷成功與否這種寫法非常脆弱。養(yǎng)成習(xí)慣action 有結(jié)果就 return 出去?？缒K dispatch 的{ root: true }是新手最容易漏的參數(shù)。不加這個(gè)參數(shù)Vuex 會(huì)只在當(dāng)前模塊內(nèi)查找 action找不到就靜默失敗或者報(bào)unknown action type。我第一次遇到的時(shí)候盯著代碼看了半小時(shí)最后發(fā)現(xiàn)就是少了個(gè) root。2.5 modules 和 namespaced拆分與隔離項(xiàng)目一大單文件 store 必然爆炸。modules 就是用來(lái)拆的而namespaced: true決定了拆完之后彼此是否隔離。// store/index.js import { createStore } from vuex import user from ./modules/user import permission from ./modules/permission import cart from ./modules/cart export default createStore({ strict: import.meta.env.DEV, modules: { user: { namespaced: true, ...user }, permission: { namespaced: true, ...permission }, cart: { namespaced: true, ...cart } } })開不開命名空間我的答案是業(yè)務(wù)模塊一律開。不開的話所有模塊的 mutation 都注冊(cè)在全局兩個(gè)模塊都定義了SET_LOADING后注冊(cè)的會(huì)覆蓋前一個(gè)這種 bug 隱蔽性極強(qiáng)。開了之后方法名變成user/SET_LOADING雖然寫起來(lái)長(zhǎng)一點(diǎn)但邊界清晰。全局的通用狀態(tài)比如 app 級(jí)別的主題、語(yǔ)言可以單開一個(gè)不開命名空間的 root 模塊但數(shù)量要克制。嵌套模塊的調(diào)用鏈路也要理清楚。假設(shè)有個(gè)setting模塊掛在user下面那么在setting的 action 里調(diào)用兄弟模塊路徑要寫成dispatch(cart/addItem, item, { root: true })。這個(gè) root 參數(shù)指的是“從根開始找”不管你現(xiàn)在在哪一層。記不住的話就記一句只要跨出當(dāng)前模塊就帶 root: true。3. 從零搭一個(gè)能落地的 Store 結(jié)構(gòu)3.1 目錄設(shè)計(jì)和模塊拆分原則先看目錄這是我用了幾年、覺得最不容易亂的一種src/ ├── store/ │ ├── index.js // 入口注冊(cè)模塊和插件 │ ├── plugins/ │ │ └── persist.js // 持久化插件 │ ├── modules/ │ │ ├── user.js // 用戶信息、登錄態(tài) │ │ ├── permission.js // 路由權(quán)限、菜單 │ │ └── cart.js // 業(yè)務(wù)模塊示例 │ └── helpers.js // 通用工具比如生成 mutation types拆分粒度怎么定我的一般原則是一個(gè)模塊對(duì)應(yīng)一個(gè)業(yè)務(wù)域而不是一個(gè)頁(yè)面。比如訂單列表和訂單詳情都屬于 order 模塊不要拆成兩個(gè)。反過(guò)來(lái)用戶和權(quán)限雖然是相關(guān)的但職責(zé)不同用戶管“我是誰(shuí)”權(quán)限管“我能看什么”拆開更好維護(hù)。模塊內(nèi)部的結(jié)構(gòu)我習(xí)慣按state → getters → mutations → actions → 導(dǎo)出的順序?qū)懞?Vuex 的執(zhí)行鏈路一致讀代碼的人從上往下看正好是數(shù)據(jù)流向。文件末尾統(tǒng)一導(dǎo)出export default { namespaced: true, state, getters, mutations, actions }有一點(diǎn)要注意如果模塊之間有數(shù)據(jù)依賴不要在模塊文件里直接import另一個(gè)模塊的 state那樣會(huì)造成循環(huán)依賴。正確方式是通過(guò)rootState讀取或者用dispatch讓對(duì)方的 action 來(lái)處理。3.2 完整實(shí)現(xiàn)一個(gè)購(gòu)物車模塊光說(shuō)概念沒(méi)意思直接上一個(gè)能跑的。假設(shè)我們要做一個(gè)購(gòu)物車需求是加商品、改數(shù)量、刪除、算總價(jià)、選中狀態(tài)管理。// store/modules/cart.js const state () ({ items: [], // { id, name, price, count, checked } submitting: false }) const getters { totalCount: state state.items.reduce((sum, i) sum i.count, 0), checkedItems: state state.items.filter(i i.checked), totalPrice: (state, getters) { // 金額用分做單位避免浮點(diǎn)誤差最后再除以 100 const cents getters.checkedItems.reduce((sum, i) sum i.price * 100 * i.count, 0) return cents / 100 }, isAllChecked: state state.items.length 0 state.items.every(i i.checked) } const mutations { ADD_ITEM(state, product) { const exist state.items.find(i i.id product.id) if (exist) { exist.count 1 } else { state.items.push({ ...product, count: 1, checked: true }) } }, UPDATE_COUNT(state, { id, count }) { const item state.items.find(i i.id id) if (item) { item.count Math.max(1, Math.min(99, count)) } }, TOGGLE_CHECK(state, id) { const item state.items.find(i i.id id) if (item) item.checked !item.checked }, TOGGLE_ALL(state, checked) { state.items.forEach(i { i.checked checked }) }, REMOVE_ITEM(state, id) { state.items state.items.filter(i i.id ! id) }, SET_SUBMITTING(state, flag) { state.submitting flag }, CLEAR(state) { state.items [] } } const actions { async checkout({ commit, state, rootState }) { if (!state.items.length) return { ok: false, msg: 購(gòu)物車是空的 } const payload state.items .filter(i i.checked) .map(i ({ productId: i.id, count: i.count })) commit(SET_SUBMITTING, true) try { const res await api.submitOrder({ items: payload, userId: rootState.user.profile?.id }) commit(REMOVE_ITEM_BATCH, res.data.removedIds) return { ok: true, orderId: res.data.orderId } } catch (e) { return { ok: false, msg: e.message } } finally { commit(SET_SUBMITTING, false) } } } export default { namespaced: true, state, getters, mutations, actions }這里有幾個(gè)我自己踩過(guò)坑之后固定下來(lái)的寫法。金額全部用“分”來(lái)算最后展示時(shí)再轉(zhuǎn)回元0.1 0.2那種經(jīng)典浮點(diǎn)問(wèn)題在電商場(chǎng)景真的會(huì)出事。數(shù)量做了Math.max(1, Math.min(99, count))的鉗制防止用戶在輸入框里手打負(fù)號(hào)或者超大批量。checkout的返回值統(tǒng)一成{ ok, msg }結(jié)構(gòu)組件層不用 try-catch直接看ok就行。另外REMOVE_ITEM_BATCH我在 mutations 里沒(méi)寫實(shí)際項(xiàng)目中應(yīng)該補(bǔ)上避免循環(huán)提交單條刪除。這類細(xì)節(jié)在真實(shí)業(yè)務(wù)里會(huì)因?yàn)榕坎僮鲗?dǎo)致幾十次 commitdevtools 面板直接被刷屏。3.3 組件里怎么調(diào)用四種方式對(duì)比Vuex 提供的調(diào)用方式有好幾種很多人只會(huì)mapState遇到方法就不知道咋辦了。列個(gè)表對(duì)照著記場(chǎng)景選項(xiàng)式寫法組合式寫法setup讀 statecomputed(() this.$store.state.user.profile)const profile computed(() store.state.user.profile)讀 getterthis.$store.getters[user/isLogin]computed(() store.getters[user/isLogin])觸發(fā) mutationthis.$store.commit(user/SET_TOKEN, t)store.commit(user/SET_TOKEN, t)觸發(fā) actionawait this.$store.dispatch(user/login, f)await store.dispatch(user/login, f)批量映射...mapState(user, [profile])storeToRefs(store.state.user)配合解構(gòu)組合式 API 里推薦用useStore加storeToRefsimport { computed } from vue import { useStore } from vuex import { storeToRefs } from pinia // 注意Vuex 沒(méi)有官方 storeToRefs這里用 toRefs 替代 export default { setup() { const store useStore() // 直接解構(gòu)會(huì)丟失響應(yīng)式必須轉(zhuǎn)成 ref const { profile, token } toRefs(store.state.user) const isLogin computed(() store.getters[user/isLogin]) function handleAdd(product) { store.commit(cart/ADD_ITEM, product) } return { profile, token, isLogin, handleAdd } } }補(bǔ)充一句上面代碼里storeToRefs是 Pinia 的 APIVuex 項(xiàng)目要用 Vue 的toRefs配合store.state.模塊名。這個(gè)區(qū)別我見過(guò)不止一個(gè)人寫混。toRefs只能處理普通響應(yīng)式對(duì)象store.state本身就是響應(yīng)式的所以能用但store.getters不行因?yàn)?getters 是每次訪問(wèn)時(shí)動(dòng)態(tài)計(jì)算的得用computed包一層。選項(xiàng)式 API 里用輔助函數(shù)會(huì)簡(jiǎn)潔很多import { mapState, mapGetters, mapActions } from vuex export default { computed: { ...mapState(cart, [items, submitting]), ...mapGetters(cart, [totalPrice, isAllChecked]), // 自己再算的派生值 isEmpty() { return this.items.length 0 } }, methods: { ...mapActions(cart, [checkout]), async onSubmit() { const res await this.checkout() if (res.ok) { // 跳轉(zhuǎn)邏輯 } } } }有個(gè)小坑要提醒mapState映射出來(lái)的名字如果和組件data里的字段重名Vue 會(huì)告警而且行為不確定。命名的時(shí)候盡量錯(cuò)開或者在映射時(shí)用對(duì)象形式重命名...mapState(cart, { cartItems: items })。3.4 嚴(yán)格模式、持久化插件和 devtools 配置嚴(yán)格模式我強(qiáng)烈建議只在開發(fā)環(huán)境開const store createStore({ strict: import.meta.env.DEV, modules: { ... } })嚴(yán)格模式下任何不經(jīng)過(guò) mutation 的 state 修改都會(huì)拋錯(cuò)[vuex] do not mutate vuex store state outside mutation handlers。這個(gè)檢查很耗性能因?yàn)樗枰疃缺O(jiān)聽整棵 state 樹。生產(chǎn)環(huán)境開嚴(yán)格模式在大型應(yīng)用里能明顯感覺到卡頓。用 Vite 的話import.meta.env.DEV就是現(xiàn)成的webpack 環(huán)境用process.env.NODE_ENV ! production。持久化這塊Vuex 本身不提供社區(qū)有插件但也都不太維護(hù)了我一般手寫一個(gè)三十行的插件// store/plugins/persist.js const KEY APP_STORE_V1 export default function createPersistPlugin(paths []) { return store { // 恢復(fù) const raw localStorage.getItem(KEY) if (raw) { try { const saved JSON.parse(raw) paths.forEach(path { const [module, field] path.split(/) const target module ? store.state[module] : store.state if (saved[path] ! undefined) { target[field] saved[path] } }) } catch (e) { localStorage.removeItem(KEY) } } // 保存做節(jié)流避免頻繁寫入 let timer null store.subscribe((mutation, state) { clearTimeout(timer) timer setTimeout(() { const data {} paths.forEach(path { const [module, field] path.split(/) const target module ? state[module] : state data[path] target?.[field] }) localStorage.setItem(KEY, JSON.stringify(data)) }, 300) }) } }用它的時(shí)候只白名單需要的字段createStore({ plugins: [createPersistPlugin([user/token, cart/items])] })為什么只白名單而不是全量存因?yàn)閟ubmitting、loading這類瞬時(shí)狀態(tài)被持久化下來(lái)刷新頁(yè)面后按鈕會(huì)一直處于 loading 狀態(tài)用戶以為卡死了。我見過(guò)一個(gè)項(xiàng)目把整個(gè) store 都存了 localStorage結(jié)果用戶重新打開頁(yè)面上次沒(méi)提交完的表單數(shù)據(jù)混著新數(shù)據(jù)出現(xiàn)問(wèn)題反饋了一堆。4. 高頻踩坑與排查實(shí)錄4.1 報(bào)錯(cuò)信息對(duì)照表先會(huì)看再看懂Vuex 的報(bào)錯(cuò)信息其實(shí)寫得挺清楚只是新手不知道往哪查。整理一張表遇到問(wèn)題先對(duì)號(hào)入座報(bào)錯(cuò)內(nèi)容大概率原因處理方式[vuex] unknown mutation type: xxx模塊沒(méi)開 namespaced或漏寫模塊前綴檢查模塊配置commit 時(shí)補(bǔ)上模塊名/[vuex] unknown action type: xxx跨模塊調(diào)用漏了{(lán) root: true }dispatch 第三個(gè)參數(shù)加上 root[vuex] unknown getter: xxxgetters 沒(méi)導(dǎo)出或訪問(wèn)路徑錯(cuò)確認(rèn) export default 里有 gettersdo not mutate vuex store state outside mutation handlers開發(fā)環(huán)境嚴(yán)格模式直接改了 state把所有賦值搬進(jìn) mutation[vuex] module namespace not found in mapState()模塊名拼錯(cuò)或模塊還沒(méi)注冊(cè)檢查 createStore 的 modules 鍵名Cannot read property xxx of undefined模塊 state 寫成了對(duì)象但被復(fù)用state 改成函數(shù)返回?cái)?shù)據(jù)改了但頁(yè)面沒(méi)更新直接改數(shù)組下標(biāo)或?qū)ο笮略鰧傩杂?mutation 里整體替換或Vue.setVue 2這張表我自己貼在工位旁邊貼了兩年新人來(lái)的時(shí)候直接拍照。說(shuō)實(shí)話Vuex 報(bào)錯(cuò)里 80% 都是“路徑寫錯(cuò)”或者“沒(méi)開命名空間”這兩類剩下 20% 是響應(yīng)式丟失。4.2 響應(yīng)式丟失的幾種典型情況Vue 2 時(shí)代最經(jīng)典的問(wèn)題state.list[0] newItem頁(yè)面不更新。原因是Object.defineProperty攔截不到數(shù)組下標(biāo)賦值。Vue 3 換成 Proxy 之后這個(gè)問(wèn)題基本解決了但如果你維護(hù)的是 Vue 2 Vuex 3 的項(xiàng)目還是得注意數(shù)組按下標(biāo)賦值用splice或者整體替換數(shù)組對(duì)象新增屬性用Vue.set(obj, key, val)刪除屬性用Vue.delete(obj, key)Vue 3 里雖然 Proxy 能攔截新增和刪除但還是有兩個(gè)容易忽略的點(diǎn)。一是reactive對(duì)象被解構(gòu)之后失去響應(yīng)式比如const { profile } store.state.user后面profile就是普通對(duì)象了怎么改頁(yè)面都不動(dòng)。二是把 state 里的對(duì)象直接賦給組件里的變量做雙向綁定v-model一改就直接改了 state繞過(guò) mutation開發(fā)環(huán)境立刻報(bào)嚴(yán)格模式錯(cuò)誤。正確的v-model寫法是這樣computed: { keyword: { get() { return this.$store.state.cart.keyword }, set(val) { this.$store.commit(cart/SET_KEYWORD, val) } } }啰嗦是啰嗦但這條鏈路是完整的devtools 能記錄到每一次輸入。如果嫌麻煩就在組件內(nèi)用本地 ref提交時(shí)再一次性寫回 store。4.3 性能問(wèn)題什么時(shí)候 store 成了瓶頸Vuex 的性能問(wèn)題我遇到過(guò)的就那么幾類但每一類都很要命。第一類是大列表全量放進(jìn) store。有個(gè)項(xiàng)目把五千條訂單數(shù)據(jù)放在 state 里每次篩選都要經(jīng)過(guò) getter頁(yè)面卡得沒(méi)法用。后來(lái)改成 store 只存篩選條件列表數(shù)據(jù)留在組件里通過(guò) action 拿問(wèn)題立刻解決。記住store 適合存“狀態(tài)”不適合存“數(shù)據(jù)集合”。第二類是在 getter 里做重計(jì)算。比如對(duì)列表做排序、格式化日期、算分組小計(jì)這些操作如果依賴頻繁變化getter 會(huì)被反復(fù)觸發(fā)。我的做法是把這類計(jì)算移到組件 computed或者在 store 里緩存一份計(jì)算結(jié)果只在源數(shù)據(jù)變化時(shí)重算。第三類是過(guò)度訂閱。mapState把整個(gè)模塊的 state 都映射進(jìn)來(lái)其中某個(gè)字段高頻變化導(dǎo)致組件整體重新渲染。用computed精確取需要的字段能緩解一部分更好的辦法是把高頻變化的狀態(tài)比如輸入框的值、鼠標(biāo)坐標(biāo)留在組件本地不要進(jìn) store。還有一種不太容易發(fā)現(xiàn)的devtools 開著跑生產(chǎn)構(gòu)建。Vuex 的 devtools 集成在開發(fā)模式下才有但如果你不小心在生產(chǎn)包里引入了開發(fā)版本的 Vue性能會(huì)差好幾倍。打包配置里確認(rèn)一下mode和define有沒(méi)有問(wèn)題這個(gè)坑我踩過(guò)一次找了一周。4.4 老項(xiàng)目遷移與工程化建議如果手上的 Vuex 項(xiàng)目要重構(gòu)我建議按這個(gè)順序推進(jìn)別一把梭。第一步先把所有this.$store的直接調(diào)用收斂成統(tǒng)一的 API 層。寫一個(gè)src/store/api.js把常用的讀寫封裝成函數(shù)比如useUser()、useCart()。這一步不改邏輯只是加一層殼風(fēng)險(xiǎn)極低。第二步把模塊的 mutation 命名規(guī)范化。原來(lái)可能叫setUser、updateUser、changeUser統(tǒng)一成SET_USER。這一步靠grep加人工核對(duì)工作量不大但收益明顯后面遷移 Pinia 時(shí)一一對(duì)應(yīng)就能改。第三步按模塊遷移。先挑一個(gè)依賴最少的模塊比如cart改成 Pinia 的defineStore然后在入口同時(shí)注冊(cè)兩套。Vuex 和 Pinia 是可以共存的只要?jiǎng)e讓同一個(gè)業(yè)務(wù)狀態(tài)兩邊都存就行。第四步清理。所有模塊遷完之后刪掉 Vuex 依賴把mapState之類的 import 全部替換。這一步用 ESLint 的自定義規(guī)則能掃出一部分剩下的靠編譯報(bào)錯(cuò)兜底。遷移過(guò)程中有個(gè)細(xì)節(jié)值得說(shuō)Pinia 的storeToRefs和 Vuex 的toRefs行為不完全一樣直接在組件里解構(gòu)很容易出問(wèn)題。我當(dāng)時(shí)的做法是先把所有組件里的解構(gòu)都改成computed遷完之后再按需優(yōu)化。寧可多寫幾行也別在響應(yīng)式上翻車。5. 幾個(gè)真實(shí)場(chǎng)景下的套路組合5.1 登錄態(tài)與路由守衛(wèi)的配合登錄態(tài)是最典型的需要 store 的場(chǎng)景但它和路由守衛(wèi)的配合有個(gè)時(shí)序問(wèn)題必須處理。守衛(wèi)在頁(yè)面渲染前執(zhí)行這時(shí)候如果 store 里的用戶信息還沒(méi)加載權(quán)限判斷就會(huì)失敗用戶被誤踢回登錄頁(yè)。我的處理方式是token 從 localStorage 同步恢復(fù)用戶信息異步加載但守衛(wèi)里做“是否已加載”的判斷沒(méi)加載就先觸發(fā) action 并等待。// permission.js router.beforeEach(async (to, from, next) { const store useStore() const token store.state.user.token if (!token) { return to.meta.public ? next() : next({ path: /login, query: { redirect: to.fullPath } }) } if (!store.state.user.permissionLoaded) { try { await store.dispatch(user/fetchProfile) await store.dispatch(permission/loadRoutes) } catch (e) { store.commit(user/RESET) return next(/login) } } if (to.meta.roles !store.getters[user/hasPermission](to.meta.roles)) { return next(/403) } next() })這里的關(guān)鍵是permissionLoaded這個(gè)標(biāo)記位。沒(méi)有它每次路由跳轉(zhuǎn)都要重新拉一次用戶信息接口壓力大不說(shuō)頁(yè)面還會(huì)閃。有了它第一次加載完之后所有跳轉(zhuǎn)都是同步判斷體驗(yàn)就順了。異步路由用router.addRoute動(dòng)態(tài)注冊(cè)注冊(cè)完再next({ ...to, replace: true })重新進(jìn)入一次否則會(huì)白屏。5.2 跨模塊協(xié)作別讓模塊之間互相 import項(xiàng)目一大模塊之間必然有協(xié)作。比如下單成功后要清空購(gòu)物車、刷新訂單列表、更新用戶積分。這三件事分屬三個(gè)模塊怎么串起來(lái)最差的做法是在order模塊里import cart from ./cart然后直接調(diào)。這樣寫會(huì)形成循環(huán)依賴打包時(shí)可能報(bào)錯(cuò)運(yùn)行時(shí)也可能拿到 undefined。正確做法是通過(guò) action 互相 dispatch// order 模塊的 action async createOrder({ commit, dispatch }, payload) { const res await api.createOrder(payload) commit(ADD_ORDER, res.data) // 跨模塊通知各自處理各自的邏輯 await dispatch(cart/clearChecked, null, { root: true }) await dispatch(user/refreshPoints, null, { root: true }) return res.data }這樣order模塊不需要知道cart內(nèi)部怎么實(shí)現(xiàn)只要知道有這么個(gè) action 就行。耦合度低測(cè)試也好寫。如果模塊數(shù)量多、協(xié)作關(guān)系復(fù)雜可以再引入一個(gè)“編排層”專門寫跨模塊的 action把業(yè)務(wù)流程集中在一處。還有個(gè)小技巧跨模塊讀取數(shù)據(jù)用 getters不要直接讀rootState.xxx.yyy。getters 是一層抽象將來(lái)內(nèi)部結(jié)構(gòu)變了只要 getter 的返回不變調(diào)用方就不用改。5.3 表單草稿和列表緩存的取舍后臺(tái)系統(tǒng)里最常見的兩個(gè)需求表單填一半切走了回來(lái)要恢復(fù)列表翻到第五頁(yè)點(diǎn)進(jìn)詳情再返回要停在第五頁(yè)。表單草稿我的做法是不進(jìn) store用sessionStorage加組件內(nèi)的watch做防抖保存。原因很簡(jiǎn)單草稿是頁(yè)面級(jí)的狀態(tài)多個(gè)表單同時(shí)編輯時(shí)放 store 會(huì)互相干擾還要處理各種清理邏輯。sessionStorage 天然按標(biāo)簽頁(yè)隔離關(guān)掉就沒(méi)了符合直覺。列表緩存反而適合進(jìn) store。因?yàn)楹Y選條件、頁(yè)碼、排序方式這些是需要跨路由保留的而且詳情頁(yè)返回時(shí)要用。做法是在list模塊里存一份query對(duì)象列表頁(yè)onMounted時(shí)讀出來(lái)發(fā)起請(qǐng)求條件變化時(shí)同步更新。要注意的是從菜單重新點(diǎn)進(jìn)列表時(shí)應(yīng)該重置從詳情返回時(shí)應(yīng)該保留這個(gè)區(qū)分靠路由的meta.keepAlive或者判斷from路徑來(lái)做。const actions { async loadList({ state, commit }, { reset false } {}) { if (reset) { commit(RESET_QUERY) } const res await api.getList(state.query) commit(SET_LIST, res.data) } }reset參數(shù)由調(diào)用方?jīng)Q定模塊本身不猜。這種“讓調(diào)用方明確表達(dá)意圖”的設(shè)計(jì)比在模塊里寫一堆 if 判斷當(dāng)前路由要清晰得多。6. 我個(gè)人在實(shí)際項(xiàng)目里的幾點(diǎn)體會(huì)寫到這里Vuex 的主要知識(shí)點(diǎn)基本都覆蓋了。最后分享幾個(gè)不太適合寫進(jìn)文檔、但實(shí)際干活時(shí)確實(shí)管用的經(jīng)驗(yàn)。第一別怕寫重復(fù)代碼。Vuex 的四段式state/getters/mutations/actions看起來(lái)很啰嗦但每多寫一行將來(lái)排查問(wèn)題時(shí)就少猜一次。我曾經(jīng)為了省事把 mutation 和 action 合并成一個(gè)函數(shù)結(jié)果 devtools 里全是匿名調(diào)用出問(wèn)題時(shí)完全不知道是誰(shuí)改的。后來(lái)老老實(shí)實(shí)拆開調(diào)試效率反而高了。第二給 store 加注釋比加文檔有用。每個(gè)模塊文件頂部寫清楚這個(gè)模塊管什么、依賴誰(shuí)、被誰(shuí)依賴比單獨(dú)維護(hù)一份文檔靠譜得多。文檔會(huì)過(guò)期代碼不會(huì)。我現(xiàn)在接手新項(xiàng)目第一件事就是看 store 模塊的頂部注釋五分鐘就能摸清業(yè)務(wù)脈絡(luò)。第三調(diào)試時(shí)善用 devtools 的 import/export。Vuex 面板可以把當(dāng)前狀態(tài)導(dǎo)出成 JSON也能導(dǎo)入一份狀態(tài)來(lái)復(fù)現(xiàn)問(wèn)題。遇到用戶反饋的詭異 bug讓對(duì)方導(dǎo)出一份狀態(tài)文件本地導(dǎo)入后就能完全復(fù)現(xiàn)當(dāng)時(shí)的場(chǎng)景比反復(fù)溝通效率高太多。這個(gè)功能知道的人不多但真的好用。第四測(cè)試只測(cè) action 和 getter。state 和 mutation 太簡(jiǎn)單測(cè)了也是形式主義。真正有價(jià)值的是 action 里的業(yè)務(wù)流程和 getter 里的計(jì)算邏輯這兩塊寫單測(cè)覆蓋率能上一個(gè)大臺(tái)階。測(cè) action 的時(shí)候記得 mock 掉commit和dispatch用jest.fn()或者vi.fn()都行斷言調(diào)用參數(shù)就夠了。最后提一句狀態(tài)管理這塊工具會(huì)換但“什么狀態(tài)該放在哪一層、變更走什么路徑、如何保證可追溯”這三個(gè)問(wèn)題不會(huì)變。把 Vuex 這套東西吃透換成 Pinia、換成任何別的方案思路都是通用的。