之前開發一個后臺管理系統，里面用到了Vue和Element-UI這個組件庫，遇到一個挺有意思的問題，和大家分享一下。

場景是這樣，在一個列表展示頁上，我使用了Element-UI的表格組件，新的需求是在原表格的基礎上支持拖拽排序。但是原有的組件本身不支持拖拽排序，而且由于是直接引入的Element-UI，不方便修改它的源碼，所以比較可行的方法只能是直接操作DOM。

具體的做法是在mounted生命周期函數里，對this.$el進行真實DOM的操作，監聽drag的一系列事件，在事件回調里移動DOM，并更新data。

HTML5 Drag事件還是挺多的，和Touch事件差不多，自己手工實現也可以，不過這里就偷了個懶，直接用了一個開源的Sortable庫，直接傳入this.$el，監聽封裝后的回調，并且根據Vue的開發模式，在移動DOM的回調里更新實際的Data數據，保持數據和DOM的一致性。

如果你以為到這就結束了，那就大錯特錯，偷過的懶遲早要還。。。本以為這個方案是很美好的，沒想到剛想調試一下，就出現了詭異的現象：A和B拖拽交換位置之后，B和A又神奇得換回去了！這是怎么回事？似乎我們的操作沒有什么問題，在真實DOM移動了之后，我們也移動了相應的data，數據數組的順序和渲染出DOM的順序應該是一致的。

問題出在哪里？我們回憶一下Vue的實現原理，在Vue2.0之前是通過defineProperty依賴注入和跟蹤的方式實現雙向綁定。針對v-for數組指令，如果指定了唯一的Key，則會通過高效的Diff算法計算出數組內元素的差異，進行最少的移動或刪除操作。而Vue2.0之后在引入了Virtual Dom之后，Children元素的Dom Diff算法和前者其實是相似的，唯一的區別就是，2.0之前Diff直接針對v-for指令的數組對象，2.0之后則針對Virtual Dom。DOM Diff算法在這里不再贅述，這里解釋的比較清楚virtual-dom diff算法

假設我們的列表元素數組是

[‘A','B','C','D']

渲染出來后的DOM節點是

[$A,$B,$C,$D]

那么Virtual Dom對應的結構就是

[{elm:$A,data:'A'},
 {elm:$B,data:'B'},
 {elm:$C,data:'C'},
 {elm:$D,data:'D'}]

假設拖拽排序之后，真實的DOM變為

[$B,$A,$C,$D]

此時我們只操作了真實DOM，改編了它的位置，而Virtual Dom的結構并沒有改變，依然是

[{elm:$A,data:'A'},
 {elm:$B,data:'B'},
 {elm:$C,data:'C'},
 {elm:$D,data:'D'}]

此時我們把列表元素也按照真實DOM排序后變成

[‘B','A','C','D']

這時候根據Diff算法，計算出的Patch為，VNode前兩項是同類型的節點，所以直接更新，即把$A節點更新成$B，把$B節點更新成$A，真實DOM又變回了