1. 從一個(gè)數(shù)據(jù)兩邊對(duì)不上的經(jīng)典場(chǎng)面說起先說一個(gè)很多人做后臺(tái)管理系統(tǒng)時(shí)都遇到過的場(chǎng)景左側(cè)是一個(gè)側(cè)邊欄顯示當(dāng)前登錄人的權(quán)限菜單右上角是一個(gè)頭像下拉顯示待辦數(shù)量中間主區(qū)域是一張訂單列表。某個(gè)用戶在主區(qū)域點(diǎn)了標(biāo)記已讀列表上的紅點(diǎn)消失了但右上角的待辦數(shù)字紋絲不動(dòng)刷新頁面之后才同步過來。這時(shí)候你八成會(huì)去翻代碼發(fā)現(xiàn)待辦數(shù)量是另一個(gè)組件自己在mounted里單獨(dú)請(qǐng)求了一遍接口兩個(gè)組件各自持有一份數(shù)據(jù)誰也不認(rèn)識(shí)誰。這類問題的本質(zhì)不是接口寫錯(cuò)了而是狀態(tài)的歸屬?zèng)]有想清楚。同一個(gè)業(yè)務(wù)事實(shí)被復(fù)制成了多份散落在不同組件里任何一處更新都得靠人工去通知其他地方。項(xiàng)目小的時(shí)候還能靠$emit一路往上拋等到組件層級(jí)到了四五層拋事件就像玩擊鼓傳花中間任何一環(huán)漏掉數(shù)據(jù)就斷了。Vuex 就是為了解決這個(gè)問題才被引入的。它是 Vue 生態(tài)里的集中式狀態(tài)管理方案把跨組件共享的那部分?jǐn)?shù)據(jù)抽出來放進(jìn)一個(gè)全局的 store 里所有組件只讀同一份數(shù)據(jù)所有修改都必須走統(tǒng)一的入口。關(guān)鍵詞落到三個(gè)單一狀態(tài)樹、單向數(shù)據(jù)流、可預(yù)測(cè)的狀態(tài)變更。這三點(diǎn)聽著像口號(hào)但后面每一處設(shè)計(jì)細(xì)節(jié)、每一個(gè)讓人抓狂的報(bào)錯(cuò)幾乎都能從這三句話里找到解釋。這篇內(nèi)容面向的是已經(jīng)寫過 Vue 組件、但被 Vuex 那幾個(gè)概念繞暈的人state、getter、mutation、action、module到底各自該管什么為什么改數(shù)據(jù)非得繞一圈 commitnamespaced開了之后為什么到處報(bào)unknown action type。我會(huì)把每個(gè)概念背后的為什么拆開講順帶把實(shí)際項(xiàng)目里踩過的坑、調(diào)試的排查順序都擺出來。看完你應(yīng)該能自己判斷一個(gè)需求該不該放進(jìn) store、該放在哪一層。2. 組件通信的五條路Vuex 只是其中一條2.1 props 與 $emit 的天花板在哪里父子組件通信最樸素父組件用props往下傳子組件用$emit往上拋。兩三層的結(jié)構(gòu)里這套東西非常清爽也沒什么性能負(fù)擔(dān)。問題出在兩個(gè)地方。第一個(gè)是跨層級(jí)。假設(shè) A 是頁面根B 是布局容器C 是卡片區(qū)D 才是真正要展示用戶信息的組件。用戶信息在 A 里拿到了要傳給 D那 B 和 C 就得各自聲明一個(gè)自己根本用不上的 prop純粹當(dāng)傳話筒。這種寫法在代碼審查里叫prop 打洞一旦中間某一層重構(gòu)改名鏈條上三四個(gè)文件都得跟著動(dòng)。第二個(gè)是兄弟組件之間沒有直接通道。同一層級(jí)的兩個(gè)組件要通信只能把狀態(tài)提升到共同的父級(jí)再由父級(jí)往下分發(fā)。當(dāng)頁面里有一張表格和右側(cè)的篩選面板需要聯(lián)動(dòng)父組件立刻變成一個(gè)中轉(zhuǎn)站data里塞滿了跟自身業(yè)務(wù)無關(guān)的東西。2.2 provide/inject、EventBus 和 Vuex 的取舍provide/inject是 Vue 自帶的跨層級(jí)注入方案祖輩提供任意后代注入。它解決打洞問題很有效但它只適合穩(wěn)定的、不頻繁變化的依賴比如主題配置、表單實(shí)例、國(guó)際化方法。原因很直接注入的值不具備響應(yīng)式的強(qiáng)約束誰改了源頭下游何時(shí)更新依賴的響應(yīng)式機(jī)制心智負(fù)擔(dān)不輕調(diào)試時(shí)也很難一眼看出來某個(gè)值是從哪個(gè)祖先流下來的。EventBus 那套寫法$bus.$emit/$on在早期項(xiàng)目里很流行它的致命弱點(diǎn)是沒有數(shù)據(jù)源。事件發(fā)出去之后狀態(tài)存在哪里還在各個(gè)組件自己身上。這等于只解決了通知沒解決共享而且事件名散落各處半年后沒人記得order-refresh到底是刷新列表還是刷新計(jì)數(shù)。Vuex 和這幾個(gè)方案的根本區(qū)別在于它先有一份數(shù)據(jù)再有通知。數(shù)據(jù)是唯一的那一份通知是數(shù)據(jù)變更的副產(chǎn)品。所以在下面這幾種情況下Vuex 的價(jià)值才真正成立多個(gè)互不相關(guān)的組件需要讀寫同一份業(yè)務(wù)數(shù)據(jù)登錄態(tài)、權(quán)限碼、購(gòu)物車、全局配置。需要跨路由保持狀態(tài)比如從列表進(jìn)詳情再返回篩選條件還在。想把數(shù)據(jù)怎么變這件事記錄下來方便回溯和調(diào)試。團(tuán)隊(duì)協(xié)作需要一條明確的紀(jì)律約束大家別亂改數(shù)據(jù)。反過來如果只是父子傳個(gè)值或者某個(gè)狀態(tài)只在單個(gè)組件內(nèi)部使用硬塞進(jìn) store 只會(huì)讓 store 變成一個(gè)巨大的雜物間。這一點(diǎn)我后面還會(huì)細(xì)說。2.3 單向數(shù)據(jù)流這條線到底約束了什么Vuex 里的數(shù)據(jù)流動(dòng)方向是固定的組件不能直接改state必須commit一個(gè)mutationmutation里再去修改state改完之后視圖跟著更新。如果要處理異步請(qǐng)求接口、定時(shí)器就先dispatch一個(gè)actionaction里拿到結(jié)果再commit。多繞的這一層不是官僚主義。它的價(jià)值在于所有對(duì) state 的寫操作都被收斂到了 mutation 里。這么一來你只要打開調(diào)試工具就能看到一個(gè)嚴(yán)格按時(shí)間排列的操作記錄每一條都帶載荷、帶時(shí)間戳甚至能時(shí)間旅行回退到之前某個(gè)狀態(tài)。如果沒有這層約束一個(gè)值在十幾個(gè)地方被直接賦值出了問題只能靠console.log一點(diǎn)點(diǎn)試。打個(gè)比方mutation 就像銀行柜臺(tái)的業(yè)務(wù)窗口。你要?jiǎng)淤~上的錢必須走窗口填單子柜員記錄一筆流水。如果允許客戶自己伸手進(jìn)金庫(kù)拿錢那賬本永遠(yuǎn)對(duì)不上。異步操作比如等審批、等外部確認(rèn)不能占著柜臺(tái)所以放到 action 那邊去排隊(duì)等結(jié)果確定了你再回來填單子。3. State 與 Getter數(shù)據(jù)源和派生數(shù)據(jù)的邊界3.1 單一狀態(tài)樹不是什么都往里塞state就是那個(gè)全局的數(shù)據(jù)對(duì)象。Vuex 采用單一狀態(tài)樹整個(gè)應(yīng)用只有一個(gè) store 實(shí)例所有模塊的狀態(tài)最終都掛在同一棵樹上。好處是定位數(shù)據(jù)非常直接看到一個(gè)字段你知道去 store 里找不用猜是哪個(gè)組件私有的。但單一不等于臃腫。我剛接觸 Vuex 的時(shí)候犯過一個(gè)典型錯(cuò)誤把組件內(nèi)部的臨時(shí)狀態(tài)也搬進(jìn)了 store比如彈窗的顯示隱藏、表格的當(dāng)前頁碼、輸入框的草稿值。結(jié)果就是 store 里躺著幾百個(gè)字段每次改動(dòng)都要寫一套 mutation代碼量翻了三倍收益為零。判斷標(biāo)準(zhǔn)其實(shí)很簡(jiǎn)單問自己三個(gè)問題這個(gè)狀態(tài)有沒有第二個(gè)人讀只有一個(gè)組件用就留在組件data里。這個(gè)狀態(tài)需不需要跨路由存活組件銷毀就沒了那也沒必要上 store。這個(gè)狀態(tài)是不是業(yè)務(wù)事實(shí)彈窗開沒開是 UI 狀態(tài)訂單已支付是業(yè)務(wù)事實(shí)。前者留本地后者進(jìn) store。在組件里讀 state 最直接的寫法是this.$store.state.count但實(shí)際項(xiàng)目里更推薦用mapState因?yàn)樗茉赾omputed里批量映射而且模板里不用寫那么長(zhǎng)的前綴。mapState有三種寫法用起來差別不小import { mapState } from vuex export default { computed: { // 寫法一數(shù)組要求 state 字段名和 computed 名一致 ...mapState([count, userInfo]), // 寫法二對(duì)象可以改名 ...mapState({ total: state state.cart.total }), // 寫法三對(duì)象 普通函數(shù)函數(shù)里可以拿到 this ...mapState({ currentOrder(state) { return state.orders.find(o o.id this.orderId) } }) } }第三種寫法有個(gè)細(xì)節(jié)必須記住只有普通函數(shù)不是箭頭函數(shù)才能拿到組件實(shí)例的this。用箭頭函數(shù)的話this指向的是模塊作用域拿不到this.orderId運(yùn)行起來就是undefined而且不會(huì)報(bào)錯(cuò)只會(huì)默默算錯(cuò)。這個(gè)坑我見過不止一次排查時(shí)對(duì)著斷點(diǎn)看了半天才發(fā)現(xiàn)是箭頭函數(shù)的問題。另外還要注意命名沖突。mapState展開在computed里如果和組件自己的 computed 同名后者會(huì)被覆蓋或者報(bào)重復(fù)鍵。穩(wěn)妥的做法是在映射時(shí)就改好名字別指望后面靠約定去避讓。3.2 Getter 的緩存機(jī)制決定了它和 methods 不是一回事getter可以理解成 store 層面的 computed。它的核心特性是基于依賴的緩存只要依賴的 state 沒變多次訪問返回的是同一個(gè)結(jié)果不會(huì)重復(fù)計(jì)算。這一點(diǎn)和 methods 有本質(zhì)區(qū)別。假設(shè)你有一個(gè)購(gòu)物車總價(jià)的計(jì)算里面要遍歷幾十個(gè)商品、做折扣判斷、算稅費(fèi)。如果寫成 methods模板里每次重新渲染都會(huì)執(zhí)行一遍寫成 getter只有cart.items或cart.discount變化時(shí)才重算。在渲染頻繁的頁面里這個(gè)差距是肉眼可見的。const store new Vuex.Store({ state: { cart: { items: [ { id: 1, price: 100, count: 2 }, { id: 2, price: 50, count: 1 } ], discount: 0.9 } }, getters: { cartTotal(state) { const sum state.cart.items.reduce((acc, item) { return acc item.price * item.count }, 0) return sum * state.cart.discount }, // getter 也可以接收其他 getter 作為第二個(gè)參數(shù) cartTotalText(state, getters) { return 合計(jì)${getters.cartTotal.toFixed(2)} 元 } } })有個(gè)關(guān)鍵限制要提前說清楚getter 默認(rèn)不能接收自定義參數(shù)。如果你寫getters.getById(3)這行代碼不會(huì)按你預(yù)期工作。需要傳參時(shí)的標(biāo)準(zhǔn)做法是讓 getter 返回一個(gè)函數(shù)getters: { getOrderById: (state) (id) { return state.orders.find(o o.id id) } }但這里有個(gè)容易忽略的代價(jià)返回函數(shù)之后緩存失效了。因?yàn)槊看握{(diào)用返回的都是一個(gè)新的函數(shù)實(shí)例Vue 無法對(duì)這個(gè)函數(shù)內(nèi)部的結(jié)果做依賴追蹤緩存。所以高頻、重計(jì)算的場(chǎng)景別用這種寫法改成在組件 computed 里基于state.orders自己find反而更快。什么時(shí)候用返回函數(shù)的 getter數(shù)據(jù)量小、調(diào)用不頻繁、主要圖個(gè)寫法方便的時(shí)候。這是個(gè)典型的方便和性能之間的取舍沒有標(biāo)準(zhǔn)答案但心里得有數(shù)。3.3 別把 getter 當(dāng)成第二個(gè) state 倉(cāng)庫(kù)還有一種常見誤用把所有能算出來的東西都塞進(jìn) getter。曾經(jīng)見過一個(gè) store里面幾十個(gè) getter其中一半只是簡(jiǎn)單取個(gè)字段比如userName: state state.user.name。這種 getter 沒有任何計(jì)算邏輯緩存也幫不上忙純粹增加了一層間接引用改代碼的時(shí)候還得多跳一次文件。我的習(xí)慣是有計(jì)算邏輯、可能被多個(gè)組件復(fù)用、或者計(jì)算成本較高的才做成 getter單純?nèi)∽侄沃苯佑胢apState或者干脆在組件里點(diǎn)出來。這條線劃清楚store 的可讀性會(huì)好很多。4. Mutation 的設(shè)計(jì)紀(jì)律為什么只能同步、只能 commit4.1 一次直接賦值引發(fā)的調(diào)試災(zāi)難先說結(jié)論在嚴(yán)格模式下任何繞過 mutation 直接修改 state 的行為都會(huì)拋錯(cuò)。我建議開發(fā)環(huán)境一定開嚴(yán)格模式const store new Vuex.Store({ state: { count: 0 }, mutations: { increment(state, payload) { state.count payload.amount } }, strict: process.env.NODE_ENV ! production })嚴(yán)格模式的原理不復(fù)雜Vuex 內(nèi)部會(huì)用深度 watcher 監(jiān)聽 state 樹的整體變化一旦發(fā)現(xiàn)有變化不是由 mutation 觸發(fā)的就拋出錯(cuò)誤。所以它的實(shí)現(xiàn)方式是深比較這在大型 state 樹上是有性能開銷的這也是為什么生產(chǎn)環(huán)境要關(guān)掉。判斷依據(jù)就是上面那段process.env.NODE_ENV構(gòu)建工具會(huì)在打包時(shí)把這段替換掉。我遇到過最隱蔽的一次問題是某個(gè)組件里寫了this.$store.state.user.info res.data開發(fā)環(huán)境直接紅屏報(bào)錯(cuò)但那位同事本地的strict是關(guān)著的所以他一直沒發(fā)現(xiàn)。等到代碼合到主分支別人一跑就炸。團(tuán)隊(duì)里最好在上線前把這條寫進(jìn)代碼規(guī)范或者用 lint 規(guī)則卡一下對(duì)$store.state的賦值操作。4.2 載荷設(shè)計(jì)對(duì)象優(yōu)先命名統(tǒng)一mutation 的第二個(gè)參數(shù)叫載荷payload它只能有一個(gè)。所以要傳多個(gè)值時(shí)習(xí)慣上打包成對(duì)象mutations: { SET_USER_INFO(state, { name, avatar, roleId }) { state.user.name name state.user.avatar avatar state.user.roleId roleId } }載荷不做成對(duì)象也不是不行但對(duì)象有個(gè)明顯好處以后要加字段不用改函數(shù)簽名調(diào)用方和定義方都不受影響。我在項(xiàng)目里統(tǒng)一約定了兩條規(guī)則執(zhí)行下來很省事。第一mutation 名用全大寫加下劃線動(dòng)詞開頭比如SET_XXX、ADD_XXX、REMOVE_XXX、CLEAR_XXX。這么寫在提交的時(shí)候一眼就能區(qū)分是動(dòng)作還是狀態(tài)字段。第二mutation 名用常量抽出來集中放在一個(gè)文件里定義和調(diào)用都引同一個(gè)常量避免手寫字符串拼錯(cuò)// mutation-types.js export const SET_USER_INFO SET_USER_INFO export const CLEAR_USER_INFO CLEAR_USER_INFO// store/user.js import { SET_USER_INFO, CLEAR_USER_INFO } from ./mutation-types const user { state: { info: {} }, mutations: { [SET_USER_INFO](state, payload) { state.info { ...state.info, ...payload } }, [CLEAR_USER_INFO](state) { state.info {} } } }不用常量也不是活不下去只是拼錯(cuò)字符串的時(shí)候編輯器不會(huì)提示運(yùn)行到那一行才炸排查成本高。用了常量之后至少能靠 ESLint 的未使用變量和拼寫檢查擋一部分。4.3 那些在 mutation 里不能做的事mutation 里除了不能異步還有幾個(gè)隱性要求值得單獨(dú)拎出來。因?yàn)?Vuex 的調(diào)試工具記錄的是每次 mutation 提交后的狀態(tài)快照它假設(shè)同步執(zhí)行完之后狀態(tài)就定型了。如果你在 mutation 里寫了回調(diào)、setTimeout、Promise.then那快照記錄下來的就是提交那一刻的狀態(tài)而此時(shí)真正的修改還沒發(fā)生。調(diào)試時(shí)看到的狀態(tài)和實(shí)際不符時(shí)間旅行也回退不到正確位置。還有一個(gè)坑是關(guān)于響應(yīng)式的給對(duì)象新增屬性要用Vue.set或者用 ES6 的展開運(yùn)算整體替換給數(shù)組按索引賦值同樣不會(huì)觸發(fā)更新得用splice或者整體替換。這本質(zhì)上是 Vue 2 響應(yīng)式系統(tǒng)的限制不是 Vuex 的鍋但因?yàn)?Vuex 里狀態(tài)結(jié)構(gòu)往往更深踩中的概率更高。mutations: { // 錯(cuò)誤這樣新增的屬性不具備響應(yīng)式 ADD_FIELD(state, { key, value }) { state.form[key] value }, // 正確 ADD_FIELD(state, { key, value }) { state.form { ...state.form, [key]: value } }, // 數(shù)組同理 UPDATE_ITEM(state, { index, item }) { state.list.splice(index, 1, item) } }整體替換看起來好像開銷大但在絕大多數(shù)業(yè)務(wù)場(chǎng)景下這些對(duì)象的體量都很小真正影響性能的是渲染而不是這里多一次淺拷貝。5. Action異步邏輯的收口與副作用管理5.1 Action 和 Mutation 的職責(zé)分界線action存在的唯一理由是mutation 必須是同步的而業(yè)務(wù)里到處是異步。所以 action 的定位很明確它就是那個(gè)先出去辦事辦完回來填單子的角色。action 函數(shù)的第一個(gè)參數(shù)是一個(gè)與 store 實(shí)例具有相同方法和屬性的 context 對(duì)象它能拿到commit、dispatch、state、getters、rootStateconst store new Vuex.Store({ actions: { async fetchOrderDetail({ commit, state, getters }, orderId) { if (state.orderDetailCache[orderId]) { commit(SET_ORDER_DETAIL, state.orderDetailCache[orderId]) return } const res await api.getOrderDetail(orderId) commit(SET_ORDER_DETAIL, res.data) } } })注意這里我在 action 里讀了state但沒有直接寫state。這是紀(jì)律action 只負(fù)責(zé)取數(shù)、判斷、編排寫操作一律交給 mutation。有人會(huì)覺得這太啰嗦直接在 action 里賦值不也行嗎運(yùn)行起來確實(shí)能跑但嚴(yán)格模式會(huì)報(bào)錯(cuò)而且時(shí)間旅行失效。一旦養(yǎng)成這個(gè)習(xí)慣后面整個(gè)調(diào)試鏈路都會(huì)廢掉。5.2 Action 返回 Promise 帶來的編排能力action 默認(rèn)返回 Promise準(zhǔn)確說是它內(nèi)部執(zhí)行的結(jié)果包成 Promise這是它最好用的特性之一。組件里可以await一個(gè) action等數(shù)據(jù)落地了再去做跳轉(zhuǎn)、彈提示這些后續(xù)動(dòng)作// 組件里 export default { data() { return { submitting: false } }, methods: { async handleSubmit() { this.submitting true try { await this.$store.dispatch(submitOrder, this.form) this.$message.success(提交成功) this.$router.push(/order/list) } finally { this.submitting false } } } }這里有個(gè)細(xì)節(jié)值得說submitting我放在了組件的 data 里而不是 store。因?yàn)樗环?wù)于這一個(gè)按鈕的 loading 狀態(tài)別的組件不需要。但如果這個(gè)提交動(dòng)作是從多個(gè)入口觸發(fā)的比如列表頁批量提交、詳情頁單個(gè)提交那 loading 就應(yīng)該提到 store 里用一個(gè)orderSubmitting字段統(tǒng)一管理避免兩個(gè)地方各轉(zhuǎn)各的圈圈用戶看著莫名其妙。action 之間也可以互相 dispatch這在組合場(chǎng)景里很有用actions: { async initUserPage({ dispatch }) { await Promise.all([ dispatch(fetchUserList), dispatch(fetchDeptTree), dispatch(fetchRoleOptions) ]) } }用Promise.all并行拉取互不依賴的接口比串行await快很多。這一點(diǎn)在頁面初始化慢的時(shí)候特別有效我一般會(huì)先畫個(gè)依賴圖誰依賴誰的結(jié)果有依賴的串行沒依賴的并行。這個(gè)判斷做完首屏?xí)r間往往能砍掉一半。5.3 競(jìng)態(tài)、重復(fù)提交和錯(cuò)誤邊界異步最麻煩的不是請(qǐng)求失敗而是請(qǐng)求回來了但不是你想要的那一次。典型場(chǎng)景是搜索框輸入聯(lián)想用戶快速輸入 abc連著發(fā)了三次請(qǐng)求服務(wù)端返回順序不保證最后可能 a 的結(jié)果覆蓋了 abc 的結(jié)果。在 action 里處理競(jìng)態(tài)我常用的辦法是給每次請(qǐng)求打一個(gè)時(shí)間戳或序號(hào)回來的時(shí)候比對(duì)一下不是最新的就丟棄let requestSeq 0 actions: { async search({ commit }, keyword) { const seq requestSeq const res await api.search(keyword) if (seq ! requestSeq) return commit(SET_SEARCH_RESULT, res.data) } }另外一個(gè)常見問題是重復(fù)提交。用戶手快點(diǎn)兩下兩次 action 都發(fā)出去了接口冪等沒做的話就是兩條臟數(shù)據(jù)。前端能做的第一層防護(hù)是按鈕 loading 置灰第二層是在 action 里做一個(gè)進(jìn)行中標(biāo)記actions: { async submitOrder({ commit, state }, payload) { if (state.submitting) return commit(SET_SUBMITTING, true) try { const res await api.submit(payload) commit(SET_SUBMIT_RESULT, res.data) } catch (e) { commit(SET_SUBMIT_ERROR, e.message) throw e } finally { commit(SET_SUBMITTING, false) } } }注意catch里我重新throw了。這一點(diǎn)很容易被忽略如果 action 內(nèi)部把錯(cuò)誤吞掉組件里await之后就永遠(yuǎn)進(jìn)不了catch用戶看不到任何提示。要么在 action 里統(tǒng)一處理比如 commit 一個(gè)錯(cuò)誤狀態(tài)由全局組件監(jiān)聽展示要么往外拋?zhàn)屨{(diào)用方處理二者選一別兩邊都做一半。6. Module 拆分項(xiàng)目變大之后怎么組織6.1 namespaced 開關(guān)與它帶來的連鎖反應(yīng)一開始大家都是單文件 store寫著寫著state里有兩百個(gè)字段mutations有八十個(gè)改一個(gè)功能要在一千行的文件里上下翻。這時(shí)候就該拆 module 了。拆模塊本身很簡(jiǎn)單麻煩的是namespaced。默認(rèn)情況下模塊的 mutation、action、getter 都注冊(cè)在全局命名空間里也就是不同模塊里同名的 action 會(huì)互相覆蓋。打開namespaced: true之后調(diào)用方式全部要加前綴const user { namespaced: true, state: () ({ info: {}, permissions: [] }), mutations: { SET_INFO(state, info) { state.info info } }, actions: { async fetchInfo({ commit }) { const res await api.getUserInfo() commit(SET_INFO, res.data) } }, getters: { hasPermission: (state) (code) { return state.permissions.includes(code) } } } export default new Vuex.Store({ modules: { user, order, cart } })開了之后調(diào)用全部變成dispatch(user/fetchInfo)、mapGetters(user, [hasPermission])。這就是很多人報(bào)unknown action type的直接原因模塊開了命名空間但調(diào)用時(shí)忘了加前綴。這個(gè)錯(cuò)誤信息看起來嚇人實(shí)際排查就是去對(duì)一下模塊名和調(diào)用名。關(guān)于state為什么用函數(shù)返回而不是直接寫對(duì)象這里也順帶說明一下。如果寫對(duì)象多個(gè)地方引用同一個(gè)模塊對(duì)象時(shí)會(huì)共享同一份 state寫成函數(shù)每次注冊(cè)都是新的實(shí)例更適合做模塊復(fù)用和 SSR 場(chǎng)景。養(yǎng)成習(xí)慣就好成本幾乎為零。6.2 跨模塊訪問與根狀態(tài)模塊之間難免要互相看一眼。比如訂單模塊需要用戶 ID用戶模塊需要清空購(gòu)物車。Vuex 給了幾個(gè)入口actions: { async createOrder({ commit, rootState, rootGetters, dispatch }, payload) { const userId rootState.user.info.id const canBuy rootGetters[user/hasPermission](order:create) if (!canBuy) throw new Error(無權(quán)限) const res await api.createOrder({ ...payload, userId }) commit(ADD_ORDER, res.data) // 第三個(gè)參數(shù)傳 root: true 才能調(diào)到別的模塊 dispatch(cart/clear, null, { root: true }) } }這里有三個(gè)點(diǎn)值得記rootState和rootGetters是 action 上下文里自帶的可以直接拿但commit和dispatch要跨模塊調(diào)用時(shí)必須傳{ root: true }否則它會(huì)默認(rèn)在當(dāng)前模塊里找找不到就報(bào)錯(cuò)。這個(gè)參數(shù)位置在 dispatch 的第三個(gè)參數(shù)很容易漏。我個(gè)人的經(jīng)驗(yàn)是跨模塊的直接訪問要盡量少。一旦 A 模塊頻繁讀 B 模塊的 state說明這兩個(gè)模塊的業(yè)務(wù)邊界沒劃清楚可能應(yīng)該合并或者把公用部分抽成一個(gè)獨(dú)立的 common 模塊。模塊拆分的目標(biāo)是降低耦合不是把一個(gè)大文件切成五個(gè)互相引用的小文件。6.3 動(dòng)態(tài)注冊(cè)模塊的適用場(chǎng)景還有一種進(jìn)階用法是registerModule運(yùn)行時(shí)動(dòng)態(tài)掛載模塊store.registerModule(orderDetail, orderDetailModule) // 用完記得卸載否則會(huì)一直占著內(nèi)存 store.unregisterModule(orderDetail)這個(gè)語法在實(shí)際業(yè)務(wù)里用得不多但有兩個(gè)場(chǎng)景特別合適。一是超大表單或復(fù)雜詳情頁只在進(jìn)入那個(gè)路由時(shí)才注冊(cè)離開就卸載能顯著減少初始化的 state 體積。二是同一份模塊要復(fù)用多個(gè)實(shí)例比如同時(shí)開多個(gè)編輯器窗口每個(gè)窗口一個(gè)模塊實(shí)例。不過要提醒一句動(dòng)態(tài)注冊(cè)的模塊在調(diào)試工具里的表現(xiàn)不如靜態(tài)模塊直觀卸載之后歷史記錄里還會(huì)殘留。如果只是圖代碼分文件用普通的靜態(tài)模塊就夠了別為了這點(diǎn)結(jié)構(gòu)上的優(yōu)雅引入額外的復(fù)雜度。7. 刷新丟數(shù)據(jù)、v-model 報(bào)錯(cuò)與性能三個(gè)上線前必須確認(rèn)的事7.1 頁面刷新之后狀態(tài)全沒了怎么辦這是新人必問的問題為什么一按 F5登錄信息和購(gòu)物車就沒了答案很樸素Vuex 的 state 存在內(nèi)存里刷新等于重新初始化。想持久化就得自己往localStorage或sessionStorage里存一份初始化的時(shí)候再讀回來。最簡(jiǎn)單的做法是在創(chuàng)建 store 時(shí)讀一次在 mutation 訂閱里存一次const store new Vuex.Store({ ... }) // 初始化時(shí)恢復(fù) const cached localStorage.getItem(vuex-cache) if (cached) { store.replaceState(Object.assign({}, store.state, JSON.parse(cached))) } // 訂閱 mutation每次變更后寫回 store.subscribe((mutation, state) { localStorage.setItem(vuex-cache, JSON.stringify(state)) })這段代碼跑起來沒問題但直接照抄會(huì)踩坑。第一個(gè)坑是全量存儲(chǔ)state 里如果有列表數(shù)據(jù)、字典緩存序列化開銷很大寫入頻率又高會(huì)讓頁面明顯卡頓。解決辦法是只存需要持久化的字段要么在訂閱里挑字段要么把持久化的部分單獨(dú)放一個(gè)模塊只序列化那一個(gè)模塊。第二個(gè)坑是敏感信息。登錄 token、用戶手機(jī)號(hào)這些不適合明文放在localStorage里容易被人翻到。這類數(shù)據(jù)的常規(guī)處理是只把 token 放進(jìn)帶 httpOnly 的 cookie 由服務(wù)端管前端 store 里只保留非敏感的展示字段。這一點(diǎn)在評(píng)審時(shí)經(jīng)常被漏掉值得單獨(dú)提一下。第三個(gè)坑是版本兼容。用戶瀏覽器里存的是上個(gè)版本的 state 結(jié)構(gòu)你新版本加了個(gè)必填字段讀回來是undefined頁面直接白屏。穩(wěn)妥的做法是存的時(shí)候帶一個(gè)版本號(hào)讀的時(shí)候版本對(duì)不上就丟棄。7.2 v-model 直接綁 state 的那個(gè)報(bào)錯(cuò)v-model綁到this.$store.state.form.name上控制臺(tái)會(huì)提示不要在 mutation 之外修改 state。原因前面說過v-model本質(zhì)是雙向綁定輸入的時(shí)候會(huì)直接給 state 賦值。標(biāo)準(zhǔn)解法是用帶 getter 和 setter 的 computedexport default { computed: { userName: { get() { return this.$store.state.user.info.name }, set(val) { this.$store.commit(user/SET_INFO, { name: val }) } } } }如果表單項(xiàng)很多一個(gè)個(gè)寫太啰嗦可以封裝一個(gè)通用的輔助函數(shù)或者在項(xiàng)目里約定表單數(shù)據(jù)先放組件本地提交時(shí)再一次性 commit。后一種做法我更推薦因?yàn)楸韱卧诰庉嬤^程中會(huì)產(chǎn)生大量中間態(tài)全塞進(jìn) store 會(huì)讓 mutation 記錄變得極其冗長(zhǎng)調(diào)試工具里翻半天找不到關(guān)鍵操作。7.3 大對(duì)象映射與渲染性能最后一個(gè)容易被忽略的點(diǎn)是mapState的粒度。有人圖省事直接...mapState([orderList, userList, dictMap])把整個(gè)大數(shù)組映射進(jìn)組件。這本身沒錯(cuò)但如果在模板里對(duì)數(shù)組做了復(fù)雜運(yùn)算過濾、排序、分組每次任何 state 變化都會(huì)觸發(fā)重算。處理辦法是把運(yùn)算挪到 getter 里讓緩存擋住大部分重復(fù)計(jì)算或者在組件里用 computed 包一層確保依賴精確。再狠一點(diǎn)的做法是分頁或虛擬滾動(dòng)別一次渲染幾千條。我在一個(gè)明細(xì)表頁面里做過對(duì)比三千條數(shù)據(jù)全量渲染滾動(dòng)時(shí)掉幀明顯改成 getter 里先算好、模板只做展示之后卡頓基本消失。還有一個(gè)排查技巧如果發(fā)現(xiàn)某個(gè)頁面明明沒改數(shù)據(jù)卻頻繁重渲染可以在watch里掛一個(gè)$store.state的深度監(jiān)聽看看是哪個(gè)字段在變。有時(shí)候罪魁禍?zhǔn)资且粋€(gè)每秒刷新的時(shí)間戳字段放在 store 里導(dǎo)致整個(gè)組件樹跟著抖。8. 報(bào)錯(cuò)排查的固定鏈路從現(xiàn)象往回倒推把常見問題按現(xiàn)象歸一下類遇到的時(shí)候照著走比漫無目的地翻代碼快得多?，F(xiàn)象最可能的原因排查動(dòng)作unknown action type: xxx模塊開了 namespaced 但調(diào)用沒加前綴或模塊壓根沒注冊(cè)檢查 dispatch 字符串與模塊名確認(rèn) modules 里有這個(gè) keyunknown mutation type同上另外注意常量拼寫全局搜 mutation 名比對(duì)大小寫頁面不更新但 state 里值變了新增屬性沒走 Vue.set數(shù)組按索引賦值檢查 mutation 里是否有obj.newKey x或arr[i] x提示不要在 mutation 外修改 statev-model 直綁、組件里直接賦值、異步回調(diào)里賦值全局搜$store.state.后面的賦值語句getter 拿到的是舊值getter 返回函數(shù)導(dǎo)致緩存失效依賴字段本身沒變確認(rèn) getter 里依賴的字段引用是否被整體替換刷新后數(shù)據(jù)丟失未做持久化檢查是否有 subscribe 寫回邏輯版本號(hào)是否匹配提交了但接口沒發(fā)出去action 里 return 前有分支提前退出或者被 loading 標(biāo)記擋了在 action 首尾打斷點(diǎn)確認(rèn)執(zhí)行路徑排查順序我一般是這樣先看調(diào)試工具的操作記錄確認(rèn) mutation 到底有沒有被提交有記錄但視圖沒變問題在響應(yīng)式?jīng)]記錄問題在調(diào)用鏈dispatch 名、模塊、守衛(wèi)條件。這個(gè)順序能把范圍快速縮到一半以內(nèi)比從頭讀代碼高效得多。還有一類問題不在 Vuex 本身而在生命周期時(shí)序。比如在created里 dispatch 一個(gè)異步 action然后在同一個(gè)created里立刻讀$store.state拿結(jié)果那必然是空的。異步就是異步得await或者在watch里等。我在項(xiàng)目里統(tǒng)一約定凡是需要依賴 store 數(shù)據(jù)的初始化邏輯一律寫在 async 函數(shù)里await不在同步代碼里碰運(yùn)氣。最后分享一個(gè)實(shí)踐中的體會(huì)Vuex 用得順不順八成取決于前期有沒有把哪些數(shù)據(jù)進(jìn) store這條線劃清楚。線劃好了五個(gè)概念各司其職代碼像流水賬一樣好讀線沒劃好store 變成垃圾場(chǎng)再多的規(guī)范也救不回來。至于新項(xiàng)目要不要上更輕的方案那是另一個(gè)話題但如果團(tuán)隊(duì)已經(jīng)在用 Vuex把它用對(duì)、用干凈收益是立刻能感受到的。