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