name: "child"
}
}
});
</script>
其实是一个很简单的列表组件，渲染出来 1 2 3 三个数字。我们先以 index 作为key，来跟踪一下它的更新。
我们接下来只关注 item 列表节点的更新，在首次渲染的时候，我们的虚拟节点列表 oldChildren 粗略表示是这样的：
[
{
tag: "item",
key: 0,
props: {
num: 1
}
},
{
tag: "item",
key: 1,
props: {
num: 2
}
},
{
tag: "item",
key: 2,
props: {
num: 3
}
}
];
在我们点击按钮的时候，会对数组做 reverse 的操作。那么我们此时生成的 newChildren 列表是这样的：
[
{
tag: "item",
key: 0,
props: {
+ num: 3
}
},
{
tag: "item",
key: 1,
props: {
+ num: 2
}
},
{
tag: "item",
key: 2,
props: {
+ num: 1
}
}
];
发现什么问题没有？key的顺序没变，传入的值完全变了。这会导致一个什么问题？
本来按照最合理的逻辑来说，旧的第一个vnode 是应该直接完全复用 新的第三个vnode的，因为它们本来就应该是同一个vnode，自然所有的属性都是相同的。
但是在进行子节点的 diff 过程中，会在 旧首节点和新首节点用sameNode对比。 这一步命中逻辑，因为现在新旧两次首部节点 的 key 都是 0了，
然后把旧的节点中的第一个 vnode 和 新的节点中的第一个 vnode 进行 patchVnode 操作。
这会发生什么呢？我可以大致给你列一下：
首先，正如我之前的文章props的更新如何触发重渲染？里所说，在进行 patchVnode 的时候，会去检查 props 有没有变更，如果有的话，会通过 _props.num = 3 这样的逻辑去更新这个响应式的值，触发 dep.notify，触发子组件视图的重新渲染等一套很重的逻辑。
然后，还会额外的触发以下几个钩子，假设我们的组件上定义了一些dom的属性或者类名、样式、指令，那么都会被全量的更新。
updateAttrs
updateClass
updateDOMListeners
updateDOMProps
updateStyle
updateDirectives
而这些所有重量级的操作（虚拟dom发明的其中一个目的不就是为了减少真实dom的操作么？），都可以通过直接复用 第三个vnode 来避免，是因为我们偷懒写了 index 作为 key，而导致所有的优化失效了。
节点删除场景
另外，除了会导致性能损耗以外，在删除子节点的场景下还会造成更严重的错误，
可以看sea_ljf同学提供的这个demo。
假设我们有这样的一段代码：
