傳統項目使用Vue時，為了提高性能需要修改Vue源碼，可行嗎？

&
export default {
name: "A",
data () {
return {
b: 1,
c: {name: "Jack"},
}
},
}
&


• 當你將 data.b 修改為 2，父組件 A 和 子組件 B 都是會重新渲染的，而子組件 C 是不會重新渲染的。為什麼父組件 A 也會重新渲染？因為是 A 的渲染依賴了 data.b （B 並不依賴 data.b，B 只是依賴 props.b）
• 而當你將 c.name 修改為 "Lucy" 時，只有組件 C 重新渲染了，因為只有 C 依賴了 c.name。

在第一種情況中，避免 A 組件重新渲染的方法是有的：把頂層組件的 data 移動到組件外部，比如使用 Vuex 的 store 中，然後子組件 B 和 C 直接從 store 中取數據，這樣 A 不依賴狀態，就不會重新渲染。

但是問題應該並非出在這裡。如我前面所述，只有父組件的渲染是多餘的，正常情況下其他兄弟組件並不會產生多餘的渲染，不應該會對性能造成明顯影響。你應該看看是不是其他地方出現了問題，比如更新數據的方式對不對，或者有沒有其他一些隱藏的地方導致大量組件出現不必要的 unmount/mount 過程，或者純粹是 App 樹結構過於龐大。

先用調試工具 profile 一下，先把問題給真正定位出來。最好是把父組件和更新數據部分的代碼貼一下。

Vue 的這套東西並不是沒有缺陷，舉幾個例子：

• 父組件通過字面量對象給子組件傳遞屬性（&），會導致每次父組件渲染都觸發子組件渲染，理論上 Vue 本身是有辦法解決這個問題的，即在編譯期就把這種字面量轉化為 computed properties. 但是開發者完全可以避免這種情況，即自行使用 computed 代替。
• 對於你能肯定不會變化的複雜數據結構，Vue 也會給它遍歷綁上 setter getter，這是多餘的，但是程序並不知道。對於這種類型的數據，我們可以使用 Object.feeze 把它凍結。

總之千萬別想著把 Vue 源碼改一下就能解決你的性能問題。因為首先 Vue 本身就有這種優化；其次是 Vue 已經迭代這麼久了，要是真的有這種銀彈，改幾行 Watcher 的代碼性能就蹭蹭蹭上去了，早就改了。最後是如果你真的對 Vue 細節有足夠了解，能通過改 Vue 源碼解決問題，那麼也完全可以在你的應用代碼裡面進行優化（參考我說的例子）。

現實情況往往是你改了Watcher 之後性能沒上去，BUG 倒折騰出了一堆。

以我對Vue的了解和對題主貼圖的理解，子組件的數據變動是不會引發父組件重新渲染的。

案例： JS Bin

這個jsbin中，按下toggle按鈕只會讓Child重新render，在console里只能看到child的輸出。

題主需要給出更好的reproduction，或者很有可能你的部分寫法是有問題的。（比如this.b的更新是用 this.b = newB， 而不是 this.b.m = "new m"）

這個很簡單，不需要修改源碼，但是你要非常精通vue的源碼，尤其是對響應式的那一塊的細節。需要人為的為了性能寫一些耦合的組件，這在mobx的文檔里也推薦過，很簡單，就是在子組件里再解.b的引用，那麼b改變，只有子組件重渲染。但是當a增加新屬性的時候，如果調用了vue.$set方法，會使得讀取過a的組件都重渲染，這個開銷沒法避免。

更暴力的，如果你用了vuex，你直接在子組件里引用容器數據就可以了，父組件不依賴於任何對象。

而且贊同 @黑貓 的觀點，重複渲染幾次，這裡不應該有性能問題，可以排查一下是不是某些組件插入的元素過多了，考慮改一下業務機制，比如表格不要一次性渲染出來，搜索提示的那些框框控制一下數量。

此外，我覺得你們項目經理水平太差，腦子也有問題，你可以考慮跳槽了。

感覺沒必要動源碼，就這個需求還沒有修源碼的必要。如果修了，那 vue 版本更新後你們怎麼 patch？

1. 典型的選擇了錯誤的架構，然後嘗試用破壞性的方案修復問題

2. 帶來問題的不是 vue 本身，而是你們組織數據的方式

3. 別把 vue 僅當個模板用

4. v=f(m)

yyx:??

謝謝各位知友的鼎力相助，和項目經理討論了很久，她願意把原來的DOM拆分組件了，但給了我新的任務：修改vue載入機制（給每個vm添加一個優先順序屬性，以此作為組件對應DOM掛載到DOM樹上的順序）。

我修改了appendChildren函數，並添加了一個用於在根組件 callhook(mounted) 之前執行，控制按優先順序掛載DOM的函數，完成了這個需求。

但總感覺性能不是很好，因為我對於暫時不掛載的元素，生成vm（要不怎麼獲取優先順序呢）但不生成其子vm，用&

& 作為佔位符，並保存這個dom對象到vm上，需時用replaceChild進行DOM替換。

最後再謝謝各位知友，2018，新年快樂

這個問題我遇到過一個類似的，分析了一陣子才解決：記vue大型表單項目的一個性能問題

總而言之就是父組件的data數據對象被改變時，patch比對所有子元素是否需要變動，而你的子組件實在太多，所以會遍歷很多很多次。你調試下Vue.prototype._update這個方法，就會發現被調用了非常多次，上面的鏈接是我分析問題的思路，你可以參考下。

很贊同黑貓的回答，請不要修改vue本身，尤其是理解還不透徹的情況下，你最好找到導致渲染時間長的最關鍵的渲染的一步，在和項目經理理論，如果貿貿然改動了vue本身，以後想升級vue版本那就蛋疼了。

如果你們覺得性能問題是vue本身產生的，那麼就不應該選擇vue這個東西，是不是考慮一下解決問題的方式出了問題，在修改源碼的這件事情上，我感覺你所說的這位項目經理應該也沒有十分的把握搞出來吧，如果有，我建議自己搞個適合你們自己的js框架。程序員最不想動的代碼就是別人的代碼，因為大多時候都不想看。

這一條不管你用react vue angular還是redux mobx vuex都適用