做后臺管理系統(tǒng)的時候幾乎繞不開Vue和Element UI這對組合。而在各種業(yè)務頁面里多級下拉篩選框又是出場率最高的組件之一什么省市區(qū)聯(lián)動了、部門層級篩選了、商品分類切換了說到底都是同一套邏輯在換皮。前陣子我在一個數(shù)據(jù)看板項目里做了一版“篩選條件區(qū)”包含四級聯(lián)動的下拉篩選折騰完發(fā)現(xiàn)這里面的坑遠不止“寫個組件就完事”那么簡單。今天把這套實現(xiàn)從選擇方案到落地細節(jié)再到踩過的坑完整梳理一遍給需要的朋友做個參考。這套方案適合誰如果你正在用Vue 2 Element UI做過或準備做帶層級關(guān)系的篩選表單如果你不想只停留在“靜態(tài)下拉框復制粘貼”的階段想搞清楚聯(lián)動篩選的內(nèi)存結(jié)構(gòu)怎么設(shè)計、遠程數(shù)據(jù)怎么按需加載、表格篩選怎么共用一套條件狀態(tài)那這篇文章應該能幫你省下不少查資料的力氣。1. 多級下拉篩選框的需求場景與方案選型1.1 多級篩選在真實業(yè)務里長什么樣先聊一下需求本身。所謂的多級下拉篩選框一般分兩種形態(tài)。第一種是“同層級多條件并列”比如篩選列表頁的數(shù)據(jù)有“時間范圍”“狀態(tài)”“來源渠道”三個下拉仨下拉之間互不依賴各篩各的。第二種是“父子層級聯(lián)動”比如選了“省份”之后“城市”下拉的選項才會跟著變選了“城市”之后“區(qū)縣”才會刷新。標題里說的“多級下拉菜單”絕大多數(shù)情況下指的是第二種也就是有依賴關(guān)系的聯(lián)動下拉。我這次遇到的需求是在訂單列表頁做一個篩選區(qū)用來篩訂單。篩選維度有四層客戶分類、客戶名稱、訂單狀態(tài)、數(shù)據(jù)權(quán)限范圍。前三層是硬聯(lián)動關(guān)系——選中客戶分類后客戶名稱的候選列表要變成該分類下的客戶訂單狀態(tài)則是獨立的。這個場景就是非常典型的“省市區(qū)聯(lián)動”的變種只是把地理層級的對象換成了業(yè)務對象。在設(shè)計階段要搞清楚的第一件事是你的數(shù)據(jù)是靜態(tài)的還是動態(tài)的。靜態(tài)就是前端一次性拿到所有層級的所有選項自己根據(jù)父級選中的值去過濾動態(tài)則是每次切換父級選項時向后端發(fā)請求拉取子級列表。這個選擇直接決定了后面代碼怎么寫也決定了用戶體驗的天花板。1.2 方案選型el-select聯(lián)動還是el-cascader級聯(lián)選擇器這是很多新手上來就會卡住的問題。Element UI里其實自帶了一個el-cascader組件它就是專門為多級選擇設(shè)計的UI上表現(xiàn)為一個下拉框點開是一整棵級聯(lián)樹。那為什么還要費勁去用多個el-select做聯(lián)動呢說到底是交互語義和數(shù)據(jù)形態(tài)決定的。對比維度el-select聯(lián)動方案el-cascader方案UI呈現(xiàn)多個獨立下拉框每個占一列單個下拉框內(nèi)部樹形展示交互習慣貼近原生表單用戶無學習成本適合省市區(qū)、分類樹等層級感知強的場景數(shù)據(jù)回顯每個字段獨立綁定回顯容易需要處理路徑數(shù)組如[廣東省,深圳市]末級語義每一級篩選項獨立參與篩選通常整體作為一個篩選項傳給后端右擊/懶加載聯(lián)動數(shù)據(jù)需自行控制請求原生支持懶加載動態(tài)顯示多級值更靈活受限我這次選擇el-select聯(lián)動原因非常直接客戶名稱這一級需要支持遠程搜索而且層級之間要根據(jù)權(quán)限動態(tài)隱藏某一級cascader在這種場景下會顯得很笨重。所以我最后是“主聯(lián)動用el-select純樹形的地方用cascader”各干各的。1.3 數(shù)據(jù)結(jié)構(gòu)的設(shè)計決定后續(xù)所有邏輯不管選哪種方案數(shù)據(jù)結(jié)構(gòu)的規(guī)劃都特別重要。很多項目做到后期發(fā)現(xiàn)代碼亂得沒法維護根源在于當初沒有把選項的數(shù)據(jù)結(jié)構(gòu)定清楚。聯(lián)動場景下我建議父級選項這么設(shè)計// 客戶分類選項 customerCategoryOptions: [ { id: 1, name: 企業(yè)客戶 }, { id: 2, name: 個人客戶 }, { id: 3, name: 渠道客戶 } ] // 客戶名稱選項每個都帶有categoryId歸屬標記 customerOptions: [ { id: 101, name: 阿里巴巴, categoryId: 1 }, { id: 102, name: 騰訊, categoryId: 1 }, { id: 201, name: 張三, categoryId: 2 }, { id: 301, name: 某渠道商, categoryId: 3 } ]關(guān)鍵點在于子級選項里要給每一個選項掛上父級id的字段categoryId。這樣不管數(shù)據(jù)是接口返回的還是前端靜態(tài)的都可以通過一次filter快速得到“當前父級下的合法子選項”而不需要為每一層單獨寫冗余的狀態(tài)。2. 基于el-select實現(xiàn)多級聯(lián)動篩選框2.1 模板骨架篩選區(qū)的基本結(jié)構(gòu)先展示我最終版的模板結(jié)構(gòu)。這一段是整個篩選區(qū)的地基后續(xù)的所有邏輯都在這個骨架里生長。template el-form reffilterForm :modelfilterForm inline classfilter-bar el-form-item label客戶分類 propcategoryId el-select v-modelfilterForm.categoryId placeholder請選擇客戶分類 clearable filterable stylewidth: 180px changehandleCategoryChange el-option v-foritem in customerCategoryOptions :keyitem.id :labelitem.name :valueitem.id / /el-select /el-form-item el-form-item label客戶名稱 propcustomerId el-select v-modelfilterForm.customerId placeholder請選擇客戶名稱 clearable filterable :disabled!filterForm.categoryId :loadingcustomerLoading stylewidth: 220px changehandleCustomerChange el-option v-foritem in currentCustomerOptions :keyitem.id :labelitem.name :valueitem.id / /el-select /el-form-item el-form-item label訂單狀態(tài) proporderStatus el-select v-modelfilterForm.orderStatus placeholder請選擇訂單狀態(tài) clearable stylewidth: 160px el-option label待付款 valuePENDING / el-option label已付款 valuePAID / el-option label已發(fā)貨 valueSHIPPED / el-option label已完成 valueFINISHED / el-option label已取消 valueCANCELED / /el-select /el-form-item el-form-item el-button typeprimary clickhandleSearch查詢/el-button el-button clickhandleReset重置/el-button /el-form-item /el-form /template這里有幾個細節(jié)我特意加了你們在實際項目里照著抄就行。第一個是子級下拉的disabled綁定filterForm.categoryId沒有選中時客戶名稱下拉直接禁用。這個在交互上是很明確的引導用戶一看就知道“得先選分類”。第二個是filterable屬性。多級篩選框到了第二級以后選項數(shù)量往往會比較多比如客戶名稱可能有幾百上千條這時候必須加filterable讓用戶能輸入關(guān)鍵字過濾否則光靠滾動找選項能把人逼瘋。第三個是每列寬度我都固定了。篩選區(qū)如果寬度不固定換行后就會變得很亂。用inline的el-form布局下顯式給每個el-select設(shè)置style寬度是我經(jīng)歷多次“對不齊”之后養(yǎng)成的習慣。2.2 聯(lián)動邏輯選父級清空子級并更新候選列表聯(lián)動篩選核心要處理的邏輯其實只有兩條父級變化時清空所有后代的值父級變化時刷新所有后代的候選數(shù)據(jù)。代碼寫多了你會發(fā)現(xiàn)所有層級之間的聯(lián)動本質(zhì)上都是這兩條規(guī)則的循環(huán)嵌套。export default { data() { return { filterForm: { categoryId: null, customerId: null, orderStatus: null }, customerCategoryOptions: [], // 全量客戶列表 allCustomerOptions: [], customerLoading: false } }, computed: { // 根據(jù)選中的categoryId過濾出當前可選的客戶列表 currentCustomerOptions() { if (!this.filterForm.categoryId) return [] return this.allCustomerOptions.filter( item item.categoryId this.filterForm.categoryId ) } }, methods: { async handleCategoryChange(value) { // 只要父級變化子級的值必須清空 this.filterForm.customerId null if (!value) return // 如果后端要求按分類動態(tài)拉取客戶列表就在這里發(fā)請求 // this.customerLoading true // const res await getCustomerList({ categoryId: value }) // this.allCustomerOptions res.data // this.customerLoading false }, handleCustomerChange(value) { // 如果還有第三級這里繼續(xù)清空第三級的值 console.log(selected customer:, value) }, handleSearch() { this.$emit(search, { ...this.filterForm }) }, handleReset() { this.filterForm { categoryId: null, customerId: null, orderStatus: null } } } }這里最容易被忽略的地方是clearable清空按鈕的處理。用戶點父級下拉的小叉號也觸發(fā)了change此時value是null如果你不處理子級會把上一次選中的值“殘留”下來。所以我上面的代碼里clear分支同樣會把后代的customerId設(shè)置為null然后return掉后續(xù)操作。計算屬性的寫法是我個人很推崇的currentCustomerOptions不單獨存儲一份可變數(shù)組而是通過filter計算得出。這樣做的最大好處是——數(shù)據(jù)源始終是單向的、可追溯的無論父級選中什么算出來的永遠是對的不會出現(xiàn)“狀態(tài)忘記同步”這種bug。只有在接口返回的候選列表需要緩存時才去維護一份categoryId - customers的映射。2.3 遠程搜索客戶名稱的數(shù)據(jù)量大了怎么辦如果客戶名稱這個下拉框有上千條數(shù)據(jù)全部一次性放進el-option里瀏覽器渲染會有明顯的卡頓感。Element UI的el-select原生支持遠程搜索就是把filterable換成filterable remote再配一個remote-method方法。el-select v-modelfilterForm.customerId placeholder請輸入客戶名稱搜索 filterable remote :remote-methodremoteSearchCustomer :loadingcustomerLoading :disabled!filterForm.categoryId stylewidth: 220px el-option v-foritem in currentCustomerOptions :keyitem.id :labelitem.name :valueitem.id / /el-selectmethods: { async remoteSearchCustomer(query) { if (!this.filterForm.categoryId) return if (query ) { this.currentCustomerOptions [] return } this.customerLoading true try { const res await getCustomerList({ categoryId: this.filterForm.categoryId, keyword: query }) this.currentCustomerOptions res.data } finally { this.customerLoading false } } }注意這里就不能用計算屬性了因為遠程搜索的結(jié)果是服務端返回的臨時數(shù)據(jù)必須用一個mutation方法把它存起來。遠程搜索有兩個容易踩的坑一個是“每次輸入都會發(fā)請求”要配合防抖另一個是“上次搜索結(jié)果還殘留”在query為空時要手動清空列表。防抖我習慣直接寫一個工具函數(shù)不引額外的庫// utils/debounce.js export function debounce(fn, delay 300) { let timer null return function (...args) { if (timer) clearTimeout(timer) timer setTimeout(() { fn.apply(this, args) }, delay) } } // 組件中 created() { this.remoteSearchCustomer debounce(this.remoteSearchCustomer, 300) }2.4 三級及以上聯(lián)動如何優(yōu)雅擴展剛才是兩級聯(lián)動可實際業(yè)務里經(jīng)常出現(xiàn)三級甚至四級聯(lián)動。有的人會把上文的代碼復制一份然后改改結(jié)果同一個方法名出現(xiàn)在多個下拉里維護起來像噩夢。我把聯(lián)動的核心邏輯封裝成了一個通用方法本質(zhì)是用一個“層級字段配置表”驅(qū)動所有層級的清空和加載// 層級配置 levelConfig: [ { key: categoryId, childKey: customerId, fetchApi: getCustomerList }, { key: customerId, childKey: orderSourceId, fetchApi: getOrderSourceList } ] methods: { async handleLevelChange(levelKey, value) { const level this.levelConfig.find(config config.key levelKey) // 清空該層級下所有后代的值 if (level level.childKey) { this.filterForm[level.childKey] null } if (!value) return // 后續(xù)可根據(jù)配置繼續(xù)加載下一級 } }這個方案看著簡單但是擴展性是質(zhì)的提升。以后要加第五級、第六級只需要在配置表里加一行然后模板里加一個el-select邏輯層完全不用動。如果你所在的項目篩選層級特別多建議一開始就按這個思路來做抽象別等到改到第三版再來重構(gòu)。3. 用el-cascader處理真正的樹形層級場景3.1 什么時候該用el-cascader在某些場景下多個el-select聯(lián)動的形態(tài)反而不合適。比如做“渠道歸屬”篩選渠道的層級可能是不固定的——有的渠道下面有子渠道有的沒有用戶希望的是“選中最終子級查詢這個子級的所有單量”但又需要能看到完整的層級關(guān)系。這種時候你用三個el-select會發(fā)現(xiàn)第三級的選項經(jīng)常是空數(shù)組因為沒那么多深度。遇到這種“層級深度不固定”“層級關(guān)系需要一眼看全”的場景直接用el-cascader就對了。它本身就是一個從省市區(qū)選擇器抽象出來的通用組件。對我這個項目里的“數(shù)據(jù)權(quán)限范圍”篩選我最終就是用了el-cascader。3.2 el-cascader基礎(chǔ)用法與動態(tài)數(shù)據(jù)加載先用最省事的靜態(tài)數(shù)據(jù)方式看個例子。假設(shè)數(shù)據(jù)源是一棵樹cascaderOptions: [ { value: company, label: 全公司, children: [ { value: sales, label: 銷售部, children: [ { value: sales-1, label: 銷售一組 }, { value: sales-2, label: 銷售二組 } ] }, { value: operations, label: 運營部, children: [ { value: operations-1, label: 運營一組 } ] } ] } ]模板部分el-cascader v-modelfilterForm.dataScope :optionscascaderOptions :props{ checkStrictly: true, emitPath: false } placeholder請選擇數(shù)據(jù)權(quán)限范圍 clearable stylewidth: 220px changehandleDataScopeChange /這里有兩個屬性的作用必須講清楚不然會踩很大的坑checkStrictly: true表示可以選擇任意一級不強制要求選中葉子節(jié)點。這個在篩選場景里非常重要。你想想如果用戶想篩“銷售部”這個整層的數(shù)據(jù)但組件強制他選到“銷售一組”才能生效那這個篩選器就是個半殘品。emitPath: false表示v-model綁定的值只保留選中節(jié)點的value而不是一個自root開始的路徑數(shù)組。如果設(shè)置成默認的emitPath為truev-model會變成類似[company, sales, sales-1]這樣的數(shù)組不僅數(shù)據(jù)形態(tài)怪傳給后端還要自己拼接非常麻煩。3.3 遠程加載大樹懶加載才是正解如果是真正的組織架構(gòu)樹或者分類層級特別深一次性把所有節(jié)點返回給前端生成樹很容易把接口和瀏覽器都干垮。cascader原生支持懶加載通過props里的lazyLoad來實現(xiàn)。el-cascader v-modelfilterForm.dataScope :propscascaderProps clearable stylewidth: 220px / script export default { data() { return { cascaderProps: { checkStrictly: true, emitPath: false, lazy: true, lazyLoad: this.lazyLoadNode } } }, methods: { async lazyLoadNode(node, resolve) { // node.level從0開始0就是根節(jié)點 const parentId node.level 0 ? null : node.value const res await fetchScopeTree({ parentId }) const nodes res.data.map(item ({ value: item.id, label: item.name, leaf: !item.hasChildren })) resolve(nodes) } } } /script懶加載有幾個點必須注意。第一leaf字段必須根據(jù)后端返回的hasChildren來正確設(shè)置否則葉子節(jié)點還會帶著展開箭頭點擊時又發(fā)一次請求白給接口增加壓力。第二lazyLoad是在props里定義的函數(shù)如果里面用到了this要確保此時的this指向組件實例如果不確定就改成箭頭函數(shù)。第三點是我實際踩過的坑切換篩選條件時cascader已展開的節(jié)點緩存不會自動清空。比如你先選了“銷售部”再切到別的條件回來看會發(fā)現(xiàn)展開的還是之前的狀態(tài)。要給cascader加一個key來強制重建或者手動調(diào)用它的clearCheckedNodes方法。4. 篩選框與表格/列表聯(lián)動的工程實踐4.1 查詢參數(shù)的統(tǒng)一管理到了這一步你的篩選區(qū)長什么樣已經(jīng)基本定了但真正讓篩選“活起來”的是跟表格數(shù)據(jù)的聯(lián)動。在實際項目里這個聯(lián)動不是簡單地把filterForm對象丟給接口就完事而是要把“查詢參數(shù)”和“分頁參數(shù)”統(tǒng)一管理起來。我習慣的做法是在頁面組件中單獨維護一個queryParams對象用它來存儲真正會傳給后端的查詢參數(shù)。filterForm只負責界面上的值當用戶點擊“查詢”按鈕時才把篩選區(qū)里的值同步過去。data() { return { queryParams: { categoryId: null, customerId: null, orderStatus: null, dataScope: null, pageNum: 1, pageSize: 10 }, tableData: [], total: 0 } }, methods: { async fetchTableData() { const res await getOrderList(this.queryParams) this.tableData res.data.records this.total res.data.total }, handleSearch() { // 查詢時重置頁碼到第一頁 this.queryParams { ...this.queryParams, ...this.filterForm, pageNum: 1 } this.fetchTableData() } }這里的核心原則是界面輸入狀態(tài)和真正的請求狀態(tài)分離。如果你把filterForm直接綁定到queryParams的引用上用戶在選下拉的過程中就可能觸發(fā)多次請求既浪費帶寬又會讓頁面閃爍。篩選區(qū)“填寫”和“生效”這兩個動作分開是工程化成熟度的分水嶺。4.2 值類型與傳參格式的坑多級篩選中值類型不一致是個高頻坑。el-select選中后v-model里的值它是option的value屬性對應的值。如果value綁定的是數(shù)字id那filterForm里就是number類型但el-cascader如果設(shè)置了emitPath為false選中的值是葉子node的value這個value可能是number也可能是string取決于你的數(shù)據(jù)定義。后端的接口參數(shù)往往對類型要求嚴格。傳到后端之前我習慣做一次類型歸一化處理尤其是cascader的值handleSearch() { const params { ...this.filterForm, // 空字符串統(tǒng)一轉(zhuǎn)成null避免后端報參數(shù)格式錯誤 categoryId: this.filterForm.categoryId || null, customerId: this.filterForm.customerId || null, // cascader的值可能是數(shù)字0要小心判斷 dataScope: this.filterForm.dataScope ?? null } this.queryParams { ...this.queryParams, ...params, pageNum: 1 } this.fetchTableData() }注意看dataScope這里我用了??空值合并運算符不是||。因為cascader的value可能從0開始如果value是00 || null會得到null這就不對了。用??只有在null或undefined時才返回右邊的默認值。這個細節(jié)坑過我好幾次排查了半小時才發(fā)現(xiàn)是值被||吞掉了。4.3 篩選條件的回顯處理URL帶參進入頁面、從詳情頁返回列表頁時需要恢復篩選條件這種需求在管理后臺也經(jīng)常出現(xiàn)。如果篩選條件存到了瀏覽器的sessionStorage里回顯時就要把值重新賦值給filterForm。有一個特別隱蔽的問題在el-select上如果回顯的值在選項中不存在下拉框會顯示這個值而不是label。比如后端返回的categoryId是99但選項里根本沒有id為99的選項那下拉就會顯示一個“99”的數(shù)字很丑也很奇怪。這時候要做一次數(shù)據(jù)兜底把不在選項里的值清掉。mounted() { const cached sessionStorage.getItem(orderFilter) if (cached) { const parsed JSON.parse(cached) this.filterForm { categoryId: this.validateValue(parsed.categoryId, this.customerCategoryOptions), customerId: this.validateValue(parsed.customerId, this.currentCustomerOptions), orderStatus: parsed.orderStatus || null } } }, methods: { validateValue(value, options) { if (value null || value undefined || value ) return null return options.some(item item.id value) ? value : null } }注意回顯客戶名稱時有個先后順序問題必須先回顯categoryId等currentCustomerOptions計算出來之后再回顯customerId。否則customerId驗證時currentCustomerOptions還是空數(shù)組就被錯誤地清掉了。這也是聯(lián)動篩選回顯的經(jīng)典順序難題。4.4 重置篩選條件的三種姿勢重置篩選看起來很簡單就是值清空但在實際項目里重置的觸發(fā)渠道有三種處理方式略有不同。第一種是“重置”按鈕點擊。這個邏輯最簡單把filterForm整體重置為空對象然后調(diào)用查詢。handleReset() { this.filterForm { categoryId: null, customerId: null, orderStatus: null, dataScope: null } // 有表單校驗的話要清除校驗狀態(tài) this.$refs.filterForm this.$refs.filterForm.clearValidate() this.handleSearch() }第二種是每個下拉框自帶的clearable清空。這種要記得在change回調(diào)里通知父組件。如果父組件里還有其他篩選邏輯聯(lián)動必要時還要手動觸發(fā)一次查詢。第三種是“重置所有默認條件”一般出現(xiàn)在篩選條件特別多、還有默認值的頁面。比如有個“只看有效數(shù)據(jù)”的開關(guān)重置時希望開關(guān)恢復到true而不是空。這種情況下我會先把默認篩選條件定義為一個常量const DEFAULT_FILTER { categoryId: null, customerId: null, orderStatus: null, dataScope: null, onlyValid: true }然后重置的時候this.filterForm { ...DEFAULT_FILTER }。用展開運算符復制一份而不是直接賦值同一個對象引用否則后續(xù)修改filterForm會改到DEFAULT_FILTER本身。5. 常見問題與排查技巧實錄寫到這里我把這段時間里碰到的典型問題和排查思路整理成一張速查表都是網(wǎng)上不一定能搜到的現(xiàn)場經(jīng)驗。5.1 問題速查表下拉框的“靈異事件”問題現(xiàn)象可能原因處理方法切換父級后子級還殘留上一次的值沒在父級change里清空子級統(tǒng)一在change回調(diào)里清空所有后代字段下拉選項很多滾動明顯卡頓一次性渲染大量el-option用遠程搜索或改用el-select-virtual-select選中的值在頁面上顯示為數(shù)字而非文本選項數(shù)據(jù)還沒加載完就賦值了先加載選項數(shù)據(jù)再回顯或做validateValue兜底清除父級篩選時子級下拉自動出現(xiàn)一段空白clearable觸發(fā)的change事件沒處理判斷value為空時同樣清空子級cascader選完整路徑后傳值給后端口徑不對默認emitPath是truev-model為數(shù)組設(shè)置emitPath:false或自行加工路徑最后一個值表格刷新時篩選條件閃爍一下又變空queryParams和filterForm沒有分離讓filterForm只控制界面請求參數(shù)單獨維護5.2 下拉框高度與樣式的自定義問題熱詞里提到“element-ui select 選擇器 高度怎么設(shè)置”這也是很多人的痛點尤其在設(shè)計稿里把下拉框高度和樣式都定義好了拿到Element UI默認樣式覺得差距很大。直接寫css覆蓋的話要小心scoped作用域。方法一在全局樣式文件中覆蓋/* 改變select選擇器的高度 */ .el-select__wrapper { min-height: 36px; }但這里要提醒一下Element UI不同版本的下拉框DOM結(jié)構(gòu)是有差異的Element UI 2.x當中輸入框的高度樣式類名是.el-input__inner而新版組件庫已經(jīng)把el-select改成了el-select__wrapper結(jié)構(gòu)。如果你用的舊版本覆蓋.el-input__inner生效新版本則要調(diào)整.el-select__wrapper的min-height。方法二給el-select加自定義類名el-select classcustom-filter-select v-model....custom-filter-select .el-select__wrapper { min-height: 36px; }如果可以接受我更推薦直接給el-select設(shè)定style寬度高度跟隨布局自適應這樣需要調(diào)整的樣式量最小。別為了好看硬把下拉框壓得很矮下拉框高度太矮會嚴重降低點擊命中率尤其在企業(yè)級后臺里目標用戶都是每天頻繁操作表的人舒適度比顏值更重要。5.3 下拉選項的防閃處理與緩存優(yōu)化頁面初始化時如果選項數(shù)據(jù)是異步加載的用戶在快速操作時經(jīng)?？吹较吕颉翱找幌掠殖鰜磉x項”觀感很差。我習慣在數(shù)據(jù)還沒回來時用v-loading給篩選區(qū)加個loading態(tài)字段級loading可以綁定到el-select的:loading屬性。另一個比較有效的優(yōu)化是選項數(shù)據(jù)緩存。以客戶名稱為例如果當前分類下有1000個客戶用戶每次重新進入頁面都要重新拉一遍接口壓力很大。可以在內(nèi)存里維護一個Map以categoryId為key緩存已拉取的數(shù)據(jù)customerCacheMap: new Map(), async fetchCustomersByCategory(categoryId) { if (this.customerCacheMap.has(categoryId)) { this.allCustomerOptions this.customerCacheMap.get(categoryId) return } this.customerLoading true try { const res await getCustomerList({ categoryId }) this.customerCacheMap.set(categoryId, res.data) this.allCustomerOptions res.data } finally { this.customerLoading false } }這種緩存的好處是用戶在多級下拉之間來回切換時已經(jīng)加載過的數(shù)據(jù)從第二次開始就走內(nèi)存不會重復發(fā)請求。缺點是內(nèi)存占用會上升所以只建議對“變動頻率低、數(shù)據(jù)量適中”的選項做緩存。像訂單狀態(tài)這種本身就是常量枚舉的根本沒必要走接口。5.4 掛載時初始數(shù)據(jù)加載的順序篩選區(qū)如果有默認值頁面的mounted里就要注意數(shù)據(jù)加載順序。比如默認選中了“企業(yè)客戶”分類那么初始化流程應該是先請求客戶分類列表分類列表返回后給filterForm.categoryId賦默認值賦值觸發(fā)handleCategoryChange如果手動賦值不觸發(fā)change則手動調(diào)用再加載客戶名稱列表客戶名稱列表返回后給filterForm.customerId賦默認值如果不按這個順序來一上來就給customerId賦值但客戶名稱選項還沒加載這個值就會成為上面的“幽靈值”——顯示成數(shù)字而不是名稱。這也是新手最容易踩的坑之一。我習慣用一個initFilter方法來統(tǒng)一控制加載順序用async/await保證步驟依次執(zhí)行async initFilter() { await this.fetchCategories() this.filterForm.categoryId 1 await this.fetchCustomersByCategory(1) this.filterForm.customerId 101 }5.5 vue-router參數(shù)聯(lián)動刷新頁面后保留篩選條件還有一個小話題是熱詞里提到的“vue路由參數(shù)”。如果你的列表頁篩選條件需要跟URL同步比如希望用戶把篩選后的URL發(fā)給別人別人打開就能看到同樣的篩選結(jié)果那就要把篩選參數(shù)映射到路由的query上。做法不復雜handleSearch() { this.$router.replace({ query: { ...this.$route.query, categoryId: this.filterForm.categoryId || undefined, customerId: this.filterForm.customerId || undefined } }).catch(() {}) this.fetchTableData() }然后mounted時從this.$route.query中恢復篩選值再走一遍數(shù)據(jù)加載。這里有個小細節(jié)$router.replace返回的是一個Promise在路由跳轉(zhuǎn)重復或取消時可能拋出NavigationDuplicated錯誤要用.catch(() {})吞掉不然控制臺會一直報紅排查時特別容易分心。寫在最后關(guān)于Vue和Element UI的多級下拉篩選框核心其實不在于你會不會用el-select或者el-cascader而在于你有沒有把“界面輸入狀態(tài)”“請求參數(shù)狀態(tài)”“數(shù)據(jù)來源狀態(tài)”這三者的關(guān)系理清楚。我這次做下來最大的體會是組件只是工具真正難的是數(shù)據(jù)結(jié)構(gòu)的設(shè)計和聯(lián)動邏輯的邊界控制。父級一變化哪些要清空、哪些要重新拉取、哪些要禁用這些規(guī)則在寫代碼之前就應該在紙上畫明白否則后期每一級新增聯(lián)動都會是一次傷筋動骨的改動。如果你也在做類似的后臺管理系統(tǒng)建議先不要急著抄組件代碼拿一張紙把你的篩選層級、依賴關(guān)系、數(shù)據(jù)來源列一遍再回來動手。把基礎(chǔ)打牢后面不管換成el-cascader還是自己封裝樹形組件都能輕松接住。這套方案里的處理思路換成其他UI庫比如Ant Design Vue的Select或Cascader一樣適用變化的只是API的寫法不變的是那三條狀態(tài)管理的原則。