multiusb key找不到驱动程序_尤大-Vue中为什么不建议用index作为key？

前言

Vue 中的 key 是用来做什么的？为什么不推荐使用 index 作为 key？常常听说这样的问题，本篇文章带你从原理来一探究竟。

阿里巴巴腾讯前端面试经验，最完整面试真题分享！www.jianshu.com

示例

以这样一个列表为例：

<ul><li>1</li><li>2</li>
</ul>

那么它的vnode 也就是虚拟 dom 节点大概是这样的。

{tag: 'ul',children: [{ tag: 'li', children: [ { vnode: { text: '1' }}]  },{ tag: 'li', children: [ { vnode: { text: '2' }}]  },]
}

假设更新以后，我们把子节点的顺序调换了一下：

{tag: 'ul',children: [
+   { tag: 'li', children: [ { vnode: { text: '2' }}]  },
+   { tag: 'li', children: [ { vnode: { text: '1' }}]  },]
}

很显然，这里的children 部分是我们本文diff 算法要讲的重点（敲黑板）。

首先响应式数据更新后，触发了渲染 Watcher 的回调函数 vm._update(vm._render())去驱动视图更新，

vm._render() 其实生成的就是vnode ，而vm._update 就会带着新的vnode 去走触发 __patch__ 过程。

我们直接进入ul 这个vnode 的patch 过程。

对比新旧节点是否是相同类型的节点：

1. 不是相同节点：

isSameNode 为false的话，直接销毁旧的vnode ，渲染新的 vnode 。这也解释了为什么 diff是同层对比。

2. 是相同节点，要尽可能的做节点的复用（都是`ul` ，进入:point_left:）。

会调用 src/core/vdom/patch.js 下的patchVNode 方法。

如果新 vnode 是文字 vnode

就直接调用浏览器的dom api 把节点的直接替换掉文字内容就好。

如果新 vnode 不是文字 vnode

如果有新 children 而没有旧 children

说明是新增 children，直接addVnodes 添加新子节点。

如果有旧 children 而没有新 children

说明是删除 children，直接removeVnodes 删除旧子节点

如果新旧 children 都存在（都存在li 子节点列表 ，进入:point_left:）

那么就是我们diff算法 想要考察的最核心的点了，也就是新旧节点的 diff 过程。

通过

  // 旧首节点let oldStartIdx = 0// 新首节点let newStartIdx = 0// 旧尾节点let oldEndIdx = oldCh.length - 1// 新尾节点let newEndIdx = newCh.length - 1

这些变量分别指向旧节点的首尾 、新节点的首尾 。

根据这些指针，在一个while 循环中不停的对新旧节点的两端的进行对比，直到没有节点可以对比。

在讲对比过程之前，要讲一个比较重要的函数：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))))
}

它是用来判断节点是否可用的关键函数，可以看到，判断是否是sameVnode ，传递给节点的 key 是关键。

然后我们接着进入diff 过程，每一轮都是同样的对比，其中某一项命中了，就递归的进入 patchVnode 针对单个vnode 进行的过程（如果这个vnode 又有children ，那么还会来到这个diff children 的过程）：

旧首节点和新首节点用sameNode 对比。
旧尾节点和新首节点用sameNode 对比
旧首节点和新尾节点用sameNode 对比
旧尾节点和新尾节点用sameNode 对比
如果以上逻辑都匹配不到，再把所有旧子节点的 key 做一个映射表，然后用新vnode 的 key去找出在旧节点中可以复用的位置。

然后不停的把匹配到的指针向内部收缩，直到新旧节点有一端的指针相遇（说明这个端的节点都被patch过了）。

在指针相遇以后，还有两种比较特殊的情况：

有新节点需要加入。如果更新完以后，oldStartIdx > oldEndIdx ，说明旧节点都被 patch完了，但是有可能还有新的节点没有被处理到。接着会去判断是否要新增子节点。
有旧节点需要删除。如果新节点先patch完了，那么此时会走 newStartIdx > newEndIdx 的逻辑，那么就会去删除多余的旧子节点。

为什么不要以index作为key？

假设我们有这样的一段代码：

    <div id="app"><ul><item:key="index"v-for="(num, index) in nums":num="num":class="`item${num}`"></item></ul><button @click="change">改变</button></div><script src="./vue.js"></script><script>var vm = new Vue({name: "parent",el: "#app",data: {nums: [1, 2, 3]},methods: {change() {this.nums.reverse();}},components: {item: {props: ["num"],template: `<div>{{num}}</div>`,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 ，而导致所有的优化失效了。

为什么不要用随机数作为key？

<item:key="Math.random()"v-for="(num, index) in nums":num="num":class="`item${num}`"
/>

其实我听过一种说法，既然官方要求一个唯一的key ，是不是可以用Math.random() 作为 key来偷懒？这是一个很鸡贼的想法，看看会发生什么吧。

首先oldVnode 是这样的：

[{tag: "item",key: 0.6330715699108844,props: {num: 1}},{tag: "item",key: 0.25104533240710514,props: {num: 2}},{tag: "item",key: 0.4114769152411637,props: {num: 3}}
];

更新以后是：

[{tag: "item",
+   key: 0.11046018699748683,props: {
+     num: 3}},{tag: "item",
+   key: 0.8549799545696619,props: {
+     num: 2}},{tag: "item",
+   key: 0.18674467938937478,props: {
+     num: 1}}
];

可以看到，key 变成了完全全新的 3 个随机数。

上面说到，diff 子节点的首尾对比如果都没有命中，就会进入key 的详细对比过程，简单来说，就是利用旧节点的 key -> index 的关系建立一个 map 映射表，然后用新节点的key 去匹配，如果没找到的话，就会调用createElm 方法 重新建立 一个新节点。

具体代码在这：

// 建立旧节点的 key -> index 映射表
oldKeyToIdx = createKeyToOldIdx(oldCh, oldStartIdx, oldEndIdx);// 去映射表里找可以复用的 index
idxInOld = findIdxInOld(newStartVnode, oldCh, oldStartIdx, oldEndIdx);
// 一定是找不到的，因为新节点的 key 是随机生成的。
if (isUndef(idxInOld)) {// 完全通过 vnode 新建一个真实的子节点createElm();
}

也就是说，咱们的这个更新过程可以这样描述：123 -> 前面重新创建三个子组件 -> 321123 -> 删除、销毁后面三个子组件 ->321 。

发现问题了吧？这是毁灭性的灾难，创建新的组件和销毁组件的成本你们晓得的伐……本来仅仅是对组件移动位置就可以完成的更新，被我们毁成这样了。

作者：ssh 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

总结

经过这样的一段旅行，diff 这个庞大的过程就结束了。

我们收获了什么？

用组件唯一的id（一般由后端返回）作为它的key ，实在没有的情况下，可以在获取到列表的时候通过某种规则为它们创建一个key ，并保证这个key 在组件整个生命周期中都保持稳定。
别用index 作为key ，和没写基本上没区别，因为不管你数组的顺序怎么颠倒，index 都是0, 1, 2 这样排列，导致 Vue 会复用错误的旧子节点，做很多额外的工作。
千万别用随机数作为key ，不然旧节点会被全部删掉，新节点重新创建，你的老板会被你气死。

—————————————————————————————————————

❤️最后

如果本文对你有帮助，就点个赞支持下吧，你的「赞」是我创作的动力。

阿里巴巴腾讯前端面试经验，最完整面试真题分享！www.jianshu.com