---

theme: cyanosis

問題描述

• 面試官：後端一次性返回10萬條數據給你，你如何處理？
• 我：歪嘴一笑，what the f**k!

問題考察點

看似無厘頭的問題，實際上考查候選人知識的廣度和深度，雖然在工作中這種情況很少遇到...

• 考察前端如何處理大量數據
• 考察候選人對於大量數據的性能優化
• 考察候選人處理問題的思考方式（關於這一點，文末會説到，大家繼續閲讀）
• ......

文末會提供完整代碼，供大家更好的理解

使用express創建一個十萬條數據的接口

若是道友對express相關不太熟悉的話，有空可以看看筆者的這一篇全棧文章（還有完整代碼哦）：《Vue+Express+Mysql全棧項目之增刪改查、分頁排序導出表格功能》

js route.get("/bigData", (req, res) => { res.header('Access-Control-Allow-Origin', '*'); // 允許跨域 let arr = [] // 定義數組，存放十萬條數據 for (let i = 0; i < 100000; i++) { // 循環添加十萬條數據 arr.push({ id: i + 1, name: '名字' + (i + 1), value: i + 1, }) } res.send({ code: 0, msg: '成功', data: arr }) // 將十萬條數據返回之 })

點擊按鈕，發請求，獲取數據，渲染到表格上

html結構如下：

```html 點擊請求加載

data() { return { arr: [], loading: false, }; },

async plan() { // 發請求，拿數據，賦值給arr } ```

方案一 直接渲染所有數據

如果請求到10萬條數據直接渲染，頁面會卡死的，很顯然，這種方式是不可取的

js async plan() { this.loading = true; const res = await axios.get("http://ashuai.work:10000/bigData"); this.arr = res.data.data; this.loading = false; }

方案二 使用定時器分組分批分堆依次渲染（定時加載、分堆思想）

• 正常來説，十萬條數據請求，需要2秒到10秒之間（有可能更長，取決於數據具體內容）
• 而這種方式就是，前端請求到10萬條數據以後，先不着急渲染，先將10萬條數據分堆分批次
• 比如一堆存放10條數據，那麼十萬條數據就有一萬堆
• 使用定時器，一次渲染一堆，渲染一萬次即可
• 這樣做的話，頁面就不會卡死了

用户所看到的效果圖是如下

效果圖

分組分批分堆函數

• 我們先寫一個函數，用於將10萬條數據進行分堆
• 所謂的分堆其實思想就是一次截取一定長度的數據
• 比如一次截取10條數據，頭一次截取0~9，第二次截取10~19等固定長度的截取
• 舉例原來的數據是：[1,2,3,4,5,6,7]
• 假設我們分堆以後，一堆分3個，那麼得到的結果就是二維數組了
• 即：[ [1,2,3], [4,5,6], [7]]
• 然後就遍歷這個二維數組，得到每一項的數據，即為每一堆的數據
• 進而使用定時器一點點、一堆堆賦值渲染即可

分組分批分堆函數（一堆分10個）

js function averageFn(arr) { let i = 0; // 1. 從第0個開始截取 let result = []; // 2. 定義結果，結果是二維數組 while (i < arr.length) { // 6. 當索引等於或者大於總長度時，即截取完畢 // 3. 從原始數組的第一項開始遍歷 result.push(arr.slice(i, i + 10)); // 4. 在原有十萬條數據上，一次截取10個用於分堆 i = i + 10; // 5. 這10條數據截取完，再截取下十條數據，以此類推 } return result; // 7. 最後把結果丟出去即可 }

創建定時器去依次賦值渲染

比如我們每隔一秒鐘去賦值渲染一次

js async plan() { this.loading = true; const res = await axios.get("http://ashuai.work:10000/bigData"); this.loading = false; let twoDArr = averageFn(res.data.data); for (let i = 0; i < twoDArr.length; i++) { // 相當於在很短的時間內創建許多個定時任務去處理 setTimeout(() => { this.arr = [...this.arr, ...twoDArr[i]]; // 賦值渲染 }, 1000 * i); // 17 * i // 注意設定的時間間隔... 17 = 1000 / 60 } },

這種方式，相當於在很短的時間內創建許多個定時任務去處理，定時任務太多了，也耗費資源啊。

實際上，這種方式就有了大數據量分頁的思想

方案三 使用requestAnimationFrame替代定時器去做渲染

關於requestAnimationFrame比定時器的優點，道友們可以看筆者的這篇文章：《性能優化之通俗易懂學習requestAnimationFrame和使用場景舉例》

反正大家遇到定時器的時候，就可以考慮一下，是否可以使用請求動畫幀進行優化執行渲染？

如果使用請求動畫幀的話，就要修改一下代碼寫法了，前面的不變化，plan方法中的寫法變一下即可，注意註釋：

js async plan() { this.loading = true; const res = await axios.get("http://ashuai.work:10000/bigData"); this.loading = false; // 1. 將大數據量分堆 let twoDArr = averageFn(res.data.data); // 2. 定義一個函數，專門用來做賦值渲染（使用二維數組中的每一項） const use2DArrItem = (page) => { // 4. 從第一項，取到最後一項 if (page > twoDArr.length - 1) { console.log("每一項都獲取完了"); return; } // 5. 使用請求動畫幀的方式 requestAnimationFrame(() => { // 6. 取出一項，就拼接一項（concat也行） this.arr = [...this.arr, ...twoDArr[page]]; // 7. 這一項搞定，繼續下一項 page = page + 1; // 8. 直至完畢（遞歸調用，注意結束條件） use2DArrItem(page); }); }; // 3. 從二維數組中的第一項，第一堆開始獲取並渲染（數組的第一項即索引為0） use2DArrItem(0); },

方案四 搭配分頁組件，前端進行分頁（每頁展示一堆，分堆思想）

這種方式，筆者曾經遇到過，當時的對應場景是數據量也就幾十條，後端直接把幾十條數據丟給前端，讓前端去分頁

後端不做分頁的原因是。他當時臨時有事情請假了，所以就前端去做分頁了。

• 數據量大的情況下，這種方式，也是一種解決方案
• 思路也是在所有數據的基礎上進行截取
• 簡要代碼如下：

js getShowTableData() { // 獲取截取開始索引 let begin = (this.pageIndex - 1) * this.pageSize; // 獲取截取結束索引 let end = this.pageIndex * this.pageSize; // 通過索引去截取，從而展示 this.showTableData = this.allTableData.slice(begin, end); }

完整案例代碼，請看筆者的這篇文章：《後端一次性返回所有的數據，讓前端截取展示做分頁》

實際上，這種大任務拆分成許多小任務，這種方式，做法，應用的思想就是分片的方式（時間），在別的場景，比如大文件上傳的時候，也有這種思想，比如一個500MB的大文件，拆分成50個小文件，一個是10MB這樣...至於大文件上傳的文章，那就等筆者有空了再寫唄...

方案五 表格滾動觸底加載（滾動到底，再加載一堆）

這裏重點就是我們需要去判斷，何時滾動條觸底。判斷方式主要有兩種

• scrollTop + clientHeight >= innerHeight
• 或
• new MutationObserver()去觀測

目前市面上主流的一些插件的原理，大致是這兩種。

筆者舉例的這是，是使用的插件v-el-table-infinite-scroll，本質上這個插件是一個自定義指令。對應npm地址：http://www.npmjs.com/package/el-table-infinite-scroll

當然也有別的插件，如vue-scroller 等：一個意思，不贅述

注意，觸底加載也是要分堆的，將發請求獲取到的十萬條數據，進行分好堆，然後每觸底一次，就加載一堆即可

在el-table中使用el-table-infinite-scroll指令步驟

安裝，注意版本號（區分vue2和vue3）

cnpm install --save [email protected]

註冊使用指令插件

js // 使用無限滾動插件 import elTableInfiniteScroll from 'el-table-infinite-scroll'; Vue.use(elTableInfiniteScroll);

因為是一個自定義指令，所以直接寫在el-table標籤上即可

```js <el-table v-el-table-infinite-scroll="load" :data="tableData"

async load() { // 觸底加載，展示數據... }, ```

案例代碼

為了方便大家演示，這裏筆者直接附上一個案例代碼，注意看其中的步驟註釋即可

```html

```

效果圖

方案六 使用無限加載/虛擬列表進行展示

什麼是虛擬列表？

• 所謂的虛擬列表實際上是前端障眼法的一種表現形式。
• 看到的好像所有的數據都渲染了，實際上只渲染可視區域的部分罷了
• 有點像我們看電影，我們看的話，是在一塊電影屏幕上，一秒一秒的看（不停的放映）
• 但是實際上電影有倆小時，如果把兩個小時的電影都鋪開的話，那得需要多少塊電影屏幕呢？
• 同理，如果10萬條數據都渲染，那得需要多少dom節點元素呢？
• 所以我們只給用户看，他當下能看到的
• 如果用户要快進或快退（下拉滾動條或者上拉滾動條）
• 再把對應的內容呈現在電影屏幕上（呈現在可視區域內）
• 這樣就實現了看着像是所有的dom元素每一條數據都有渲染的障眼法效果了

關於前端障眼法，在具體工作中，如果能夠巧妙使用，會大大提升我們的開發效率的

寫一個簡單的虛擬列表

效果圖

這裏筆者直接上代碼，大家複製粘貼即可使用，筆者寫了一些註釋，以便於大家理解。當然也可以去筆者的倉庫中去瞅瞅哦，GitHub倉庫在文末

代碼

```html

```

使用vxetable插件實現虛擬列表

如果不是列表，是table表格的話，筆者這裏推薦一個好用的UI組件，vxetable，看名字就知道做的是表格相關的業務。其中就包括虛擬列表。

vue2和vue3版本都支持，性能比較好，官方説：虛擬滾動（最大可以支撐 5w 列、30w 行）

強大！

官方網站地址：http://vxetable.cn/v3/#/table/scroll/scroll

效果圖

效果很絲滑

安裝使用代碼

注意安裝版本，筆者使用的版本如下：

cnpm i xe-utils [email protected] --save

main.js

js // 使用VXETable import VXETable from 'vxe-table' import 'vxe-table/lib/style.css' Vue.use(VXETable)

代碼方面也很簡單，如下：

```html

```

方案七 開啟多線程Web Worker進行操作

本案例中，使用Web Worker另外開啟一個線程去操作代碼邏輯，收益並不是特別大（假如使用虛擬滾動列表插件的情況下）

不過也算是一個拓展的思路吧，面試的時候，倒是可以説一説，提一提。

對Web Worker不熟悉的道友們，可以看看筆者之前的這篇文章：《性能優化之使用vue-worker插件（基於Web Worker）開啟多線程運算提高效率》

方案八 未雨綢繆，防患於未然

以下為筆者愚見，僅供參考...

• 在上述解決方案都説完以後，並沒有結束。
• 實際上本題目在考查候選人知識的廣度和深度以外，更是考查了候選人的處理問題的思考方式，這一點尤其重要！
• 筆者曾做過候選人去求職，也曾做過面試官去面試。就程序員開發工作而言，技術知識點不熟悉，可以快速學習，如文檔、谷歌、百度、技術交流羣，相關同事都可提供一定的支持
• 更重要的是看中候選人的思考方式，思維模式
• 試想，兩個候選人實力水平差不多，但是一個只知道埋頭苦幹，有活就幹，不去斟酌；而另外一個卻是在用心工作的時候，也會仰望星空，會分析如何幹活能夠高性價比地完成任務，注重過程與結果
• 這樣的話，哪個更加受歡迎一些呢？

如果筆者是候選人，筆者在説了上述7種方案以後，會再補充第八種方案：未雨綢繆，防患於未然

---

場景模擬

面試官隨意打量着其手中我的簡歷，撫須怪叫一聲：“小子，後端要一次性返回10萬條數據給你，你如何處理？”

我眉毛一挑，歪嘴一笑：“在上述7種方案陳述完以後，我想類似的問題，我們可以從根本上去解決。即第八種方案，要未雨綢繆，防患於未然。”

“哦？”面試官心中疑惑，緩緩放下我的簡歷：“願聞其詳。”

我不緊不慢地答道：“在具體開發工作中，我們在接到一個需求時，在技術評審期間，我們就要和後端去商量比較合適的技術解決方案。這個問題是後端要一次性返回我10萬條數據，重點並不在10萬條這麼多數據，而在於後端為什麼要這樣做？”

面試官抬頭，認真聽了起來。

我一字一頓地説道：“除去業務真正需要這種方案的話，後端這樣做的原因大致有兩種，第一種他不太懂sql的limit語句，但這基本不可能，第二種就是他有事情，隨便敷衍寫了一下。所以，就是要和他溝通，從大數據量接口請求時長過長，以及過多的dom元素渲染導致性能變差，以及項目的可維護性等角度去溝通，我相信只要正確的溝通，就能從根源上去避免這種不太合理的情況發生。”

面試官又突然狡黠地發問：“要是溝通以後，後端死活不給你分頁呢？你咋辦？你的溝通無效果！你如何處理！人家不聽你的！”似乎是覺得這個問題很刁鑽，他雙臂抱在胸前，靠在椅背上，等待着我臉上即將綻放的的回答不上來地尷尬笑容。

我內心冷哼一聲：雕蟲小技...

我盯着面試官的眼睛，認真説道：“如果工作中溝通無效果，要麼是我自己溝通語言表達的問題，這一點我會注意，不斷提升自己的溝通技巧和説話方式，要麼就是...”

我聲音揚起了三分：“我溝通的這個人有問題！他工作摸魚偷懶耍滑！固執己見！為難他人！高高在上！自以為是！這種情況下，我會找到我的直屬領導去介入，因為這已經不是項目的需求問題了，而是員工的基本素養問題！”

停頓了一秒，我聲音又柔和了幾分：“但是，但是我相信咱們公司員工中是絕對沒有這樣的人存在的，各個都是能力強悍，態度端正的優秀員工。畢竟咱們公司在行業中久負盛名，我也是因此慕名而來的。您説對吧？”

面試官眼中閃過震驚之色，他沒有想到我居然把皮球又踢給他了，不過他為了維持形象，旋即恢復了鎮定，只是面部肌肉在止不住的微微顫抖。

我又補充道：“實際上在工作中，前端作為比較貼近用户的角色而言，需要和各個崗位的同事進行溝通，比如後端、產品、UI、測試等。我們需要通過合理的溝通方式，去提升工作效率，完成項目，實現自己的價值，為公司創造收益，我想這是每一個員工需要做的，也是必須要做到的。”

面試官又撫須怪叫一聲：“小子表現還行，你被錄用了！一個月工資2200，自帶電腦，無社無金，007工作制，不能偷吃公司零食，以及...”

我：阿噠...

總結

有效的溝通，源自於解決問題的思維模式，在多數情況下，重要性，大於當下所掌握的技術知識點

• 網站效果演示地址：http://ashuai.work:8888/#/bigData
• GitHub倉庫地址：http://github.com/shuirongshuifu/elementSrcCodeStudy

如果覺得文章幫到了您，歡迎不吝star哦 ^_^