华山资源网

详解为什么Vue中不要用index作为key(diff算法)
网络编程 2024/12/24 佚名
3 1

前言

Vue 中的 key 是用来做什么的？为什么不推荐使用 index 作为 key？常常听说这样的问题，本篇文章带你从原理来一探究竟。
另外本文的结论对于性能的毁灭是针对列表子元素顺序会交换、或者子元素被删除的特殊情况，提前说明清楚，喷子绕道。

本篇已经收录在 Github 仓库，欢迎 Star：
https://github.com/sl1673495/blogs/issues/39

示例

以这样一个列表为例：

<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，进入"htmlcode"> 

 // 旧首节点
 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 的过程 ）：

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

然后不停的把匹配到的指针向内部收缩，直到新旧节点有一端的指针相遇（说明这个端的节点都被patch过了）。
在指针相遇以后，还有两种比较特殊的情况：

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

为什么不要以index作为key？

节点reverse场景

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

  <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="/UploadFiles/2021-04-02/vue.js">


其实是一个很简单的列表组件，渲染出来 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的属性或者类名、样式、指令，那么都会被全量的更新。


    
  
  1. updateAttrs
    2. 
  
  2. updateClass
    3. 
  
  3. updateDOMListeners
    4. 
  
  4. updateDOMProps
    5. 
  
  5. updateStyle
    6. 
  
  6. updateDirectives
    7. 



而这些所有重量级的操作（虚拟dom发明的其中一个目的不就是为了减少真实dom的操作么？），都可以通过直接复用 第三个vnode 来避免，是因为我们偷懒写了 index 作为 key，而导致所有的优化失效了。




节点删除场景




另外，除了会导致性能损耗以外，在删除子节点的场景下还会造成更严重的错误，




可以看sea_ljf同学提供的这个demo。




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







<body>
 <div id="app">
  <ul>
   <li v-for="(value, index) in arr" :key="index">
    <test />
   </li>
  </ul>
  <button @click="handleDelete">delete</button>
 </div>
 </div>
</body>
<script>
 new Vue({
  name: "App",
  el: '#app',
  data() {
   return {
    arr: [1, 2, 3]
   };
  },
  methods: {
   handleDelete() {
    this.arr.splice(0, 1);
   }
  },
  components: {
   test: {
    template: "<li>{{Math.random()}}</li>"
   }
  }
 })
</script>






那么一开始的 vnode列表是：







[
 {
  tag: "li",
  key: 0,
  // 这里其实子组件对应的是第一个 假设子组件的text是1
 },
 {
  tag: "li",
  key: 1,
  // 这里其实子组件对应的是第二个 假设子组件的text是2
 },
 {
  tag: "li",
  key: 2,
  // 这里其实子组件对应的是第三个 假设子组件的text是3
 }
];






有一个细节需要注意，正如我上一篇文章中所提到的为什么说 Vue 的响应式更新比 React 快？，Vue 对于组件的 diff 是不关心子组件内部实现的，它只会看你在模板上声明的传递给子组件的一些属性是否有更新。




也就是和v-for平级的那部分，回顾一下判断 sameNode 的时候，只会判断key、 tag、是否有data的存在（不关心内部具体的值）、是否是注释节点、是否是相同的input type，来判断是否可以复用这个节点。







<li v-for="(value, index) in arr" :key="index"> // 这里声明的属性
 <test />
</li>






有了这些前置知识以后，我们来看看，点击删除子元素后，vnode 列表 变成什么样了。







[
 // 第一个被删了
 {
  tag: "li",
  key: 0,
  // 这里其实上一轮子组件对应的是第二个 假设子组件的text是2
 },
 {
  tag: "li",
  key: 1,
  // 这里其实子组件对应的是第三个 假设子组件的text是3
 },
];






虽然在注释里我们自己清楚的知道，第一个 vnode 被删除了，但是对于 Vue 来说，它是感知不到子组件里面到底是什么样的实现（它不会深入子组件去对比文本内容），那么这时候 Vue 会怎么 patch 呢？




由于对应的 key使用了 index导致的错乱，它会把


    
  
  1. 原来的第一个节点text: 1直接复用。
    2. 
  
  2. 原来的第二个节点text: 2直接复用。
    3. 
  
  3. 然后发现新节点里少了一个，直接把多出来的第三个节点text: 3 丢掉。
    4. 



至此为止，我们本应该把 text: 1节点删掉，然后text: 2、text: 3 节点复用，就变成了错误的把 text: 3 节点给删掉了。




为什么不要用随机数作为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。

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




总结




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




我们收获了什么？


    
  
  1. 用组件唯一的 id（一般由后端返回）作为它的 key，实在没有的情况下，可以在获取到列表的时候通过某种规则为它们创建一个 key，并保证这个 key 在组件整个生命周期中都保持稳定。
    2. 
  
  2. 如果你的列表顺序会改变，别用 index 作为 key，和没写基本上没区别，因为不管你数组的顺序怎么颠倒，index 都是 0, 1, 2 这样排列，导致 Vue 会复用错误的旧子节点，做很多额外的工作。列表顺序不变也尽量别用，可能会误导新人。
    3. 
  
  3. 千万别用随机数作为 key，不然旧节点会被全部删掉，新节点重新创建，你的老板会被你气死。
    4.
华山资源网 Design By www.eoogi.com
广告合作：本站广告合作请联系QQ：858582 申请时备注：广告合作（否则不回）
免责声明：本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除！
华山资源网 Design By www.eoogi.com
www.eoogi.com 华山资源网
120,135影音资源
344,641技术资源
22,817软件资源
435,032站长资源
一句话新闻
一口气升级7个大模型SaaS应用，百度智能云：突出一个“开箱即用” - 2024/12/24

这一波大模型产业落地浪潮里，不少企业其实处在 “干瞪眼“的状态。

一种情况是，很多大模型产品看得见却摸不着，在台上一个个遥遥领先——今天Sora技精四座，明天英伟达的机器人又赢得满堂彩，可是到了台下一问：啥时候能用上啊？答曰：遥遥无期。

另一种情况是，企业想用上大模型，却又难免瞻前顾后——既要考虑场景融合，又得兼顾安全性，还要考虑打通现有系统，再加上各种部署成本和繁琐的采购流程……最后只能拂袖：罢了，再等等吧。

稳了！魔兽国服回归的3条重磅消息！官宣时间再确认！

昨天有一位朋友在大神群里分享，自己亚服账号被封号之后居然弹出了国服的封号信息对话框。

这里面让他访问的是一个国服的战网网址，com.cn和后面的zh都非常明白地表明这就是国服战网。

而他在复制这个网址并且进行登录之后，确实是网易的网址，也就是我们熟悉的停服之后国服发布的暴雪游戏产品运营到期开放退款的说明。这是一件比较奇怪的事情，因为以前都没有出现这样的情况，现在突然提示跳转到国服战网的网址，是不是说明了简体中文客户端已经开始进行更新了呢？

更新日志

友情链接

杰晶网络 DDR爱好者之家 桃源资源网 杰网资源 富贵资源网 南强小屋 铁雪资源网 幽灵资源网 万梅资源网 狼山资源网 白云岛资源网 昆仑资源网 相思资源网 明霞山资源网 内蒙古资源网 黑松山资源网 茶园资源网 饿虎岗资源网 大旗谷资源网 常春岛资源网 岱庙资源网 兴国资源网 快活林资源网 蝙蝠岛资源网 帝王谷资源网 白云城资源网 伏龙阁资源网 清风细雨楼 天枫庄资源网 圆月山庄资源网 无争山庄资源网 神水资源网 移花宫资源网 神剑山庄资源网 无为清净楼资源网 金钱帮资源网 丐帮资源网 华山资源网 极乐门资源网 小李飞刀资源网 凤求凰客栈 风云阁资源网 金狮镖局 鸳鸯亭资源网 千金楼资源网 更多链接
华山资源网 Design By www.eoogi.com