產品反饋表單頁太卡了，這是乙個有意思的情況，讓我看看。
如圖所見，當在 input 輸入資料的時候，連續輸入會感覺明顯的延遲。
那個專案最多情況下，表單數量達到千數。筆者在 demo 裡簡化實現，並把表單數量提公升到 10000，把下面的**貼上執行一邊就能得到卡頓效果。
object.defineproperty(obj, key, ,
set: function reactivesetter (newval)
})// ------ dep 的結構如下
/**/
// ------- watcher 的結構
/**/
總之在這裡執行的更新語句是
expression: "function () "vue.prototype._update語句進行更新。
ok，知識梳理完畢，那麼到底 _update 裡怎麼做的，讓頁面更新渲染如此之慢呢？
在vue.prototype._update打斷點除錯，如下圖：
省略函式進入步驟 patch -> patchvnode -> updatechildren，直到 updatechildren 發現核心比對邏輯
比對這 10000 個節點。簡單來說相同 key 和標籤名的被判定為相同節點，相同節點還得繼續去遞迴比對其子節點是否相同。並且比對過程中，還需要判定更新的內容裡有 attr、 class、listener、style 等等資訊，由此產生的計算量還是挺大的。筆者下圖與本次除錯無關，但能簡單揭示下比對邏輯。
筆者在這裡 pachvnode 裡執行 updatechildren 的地方，列印耗時，發現當 input 為 1000 項的時候每輸入乙個字元耗時一般是個位數的毫秒。
而 input 為 10000 項時，每個字元輸入響應需要 50～100 毫秒的話，快速輸入一串字元，產生的卡頓感就會比較厲害。
而在我們實際的專案中，表單複雜的多，比對的層級深，或許 1000 不到的表單就能產生這樣的效果。
既然更新 10000 個節點費力，那何不縮小更新範圍呢。把表單拆成若干組，每組包裹在元件中，輸入時只會更新那個元件，影響範圍就笑得多。由此產生的更新如下：
本質上這就是乙個原則，不要在乙個 vue 元件上繫結那麼多的元素，請拆分成多個子元件。。
記一次關於vue效能問題
當時開發專案的時候，涉及到乙個操作列表 不是單純展示的列表，裡面包含很多操作功能 的功能。把列表的每個小item寫成乙個子元件，當時寫子元件沒有考慮到資料量的問題。所以在寫子元件，並沒有做什麼優化，而且裡面還加了form表單校驗，裡面還有很多事件處理，樣式處理等等複雜的邏輯。注意 首先需要從設計上面...
Keepfast 是前端乙個效能分析工具
keepfast 是乙個效能分析工具，能夠分析 的資源構建效能和頁面效能，生成效能報告並提供優化建議，讓效能監控更方便。主要特性 訪問此頁面可檢視效能報告效果 npm install g lighthouse gitee keepfast先為你的專案建立配置檔案 進入你的專案目錄 cd path t...
SQL 記乙個查詢問題
有部門表和部門管理員表，部門表比較常規，反常的是部門管理員表。這張表是etl整理出來的表，包含各部門的主管 秘書 機要員資訊等等。下面把關鍵字段列出來 部門表，department dept code dept name 50040001 部門150040002 部門250040003 部門3部門管...