Vue的transition-group与Virtual Dom Diff算法的使用

idxInOld = isDef(newStartVnode.key)
? oldKeyToIdx[newStartVnode.key] : findIdxInOld(newStartVnode, oldCh, oldStartIdx, oldEndIdx)
if (isUndef(idxInOld)) { // New element
createElm(newStartVnode, insertedVnodeQueue, parentElm, oldStartVnode.elm, false, newCh, newStartIdx)
} else {
vnodeToMove = oldCh[idxInOld] if (sameVnode(vnodeToMove, newStartVnode)) {
patchVnode(vnodeToMove, newStartVnode, insertedVnodeQueue, newCh, newStartIdx)
oldCh[idxInOld] = undefined
canMove && nodeOps.insertBefore(parentElm, vnodeToMove.elm, oldStartVnode.elm)
} else {
// same key but different element. treat as new element
createElm(newStartVnode, insertedVnodeQueue, parentElm, oldStartVnode.elm, false, newCh, newStartIdx)
}
}
newStartVnode = newCh[++newStartIdx] }
}

首先会是oldStartVnode跟newStartVnode做对比，当然如果它们类型一致就会进入patch流程；
接着又尝试oldEndVnode与newEndVnode做对比，继续跳过；
明显前面两个判断都没有canMove的身影，因为这里patch后是不用移动元素的，都是头跟头，尾跟尾，但是后面就不一样了；再继续oldStartVnode与newEndVnode对比，canMove开始出现了，这里旧的头节点从头部移动到尾部了，进行patch后，oldStartElem也需要移动到oldEndElem后面;
同样的如果跳过上一个判断，继续oldEndVnode与newStartVnode做对比，也会发生同样的移动，只是这次是把oldEndElm移动到oldStartElm前面去；
如果再跳过上面的判断，就需要在旧的Vnode节点上建立一个oldKeyToIdx的map了（很明显并不是所有的Vnode都会有key，所以这个map上并不一定有所有旧Vnode，甚至很有可能是空的），然后如果newStartVnode上定义了key的话在个map里面尝试去找出对应的oldVnode位置（当然不存在的话，就可以理所当然的认为这是新的元素了）；又如果newStartVnode没有定义key，它就会暴力去遍历所有的旧Vnode节点看看能否找出一个类型一致的可以进行patch的VNode；说明定义key还是很重要的，现在Vue的模板上都会要求for循环列表的时候要定义key，可以想象如果我们直接使用下标作为key的话会怎样尼；根据sameVnode方法：

function sameVnode (a, b) {
 return (
  a.key === b.key && (
   (
    a.tag === b.tag &&
    a.isComment === b.isComment &&
    isDef(a.data) === isDef(b.data) &&
    sameInputType(a, b)
   ) || (
    isTrue(a.isAsyncPlaceholder) &&
    a.asyncFactory === b.asyncFactory &&
    isUndef(b.asyncFactory.error)
   )
  )
 )
}

首先会判断key是否一致，然后是tag类型还有input类型等等。

所以下标作为key的时候，很明显key会很容易就会判断为一致了，其次就是要看tag类型等等。