为什么不要用index作为列表key值

我们都知道目前框架都采用了虚拟dom，主要目的就是减少频繁dom操作，提高页面性能。

当触发视图变化的时候，框架会先计算虚拟dom的前后变化，在nextTick即下一个微任务上做视图的更新。

计算虚拟dom的变化的具体流程不讲了，往上有很多，今天主要聊下为什么不要用数据的index值作为列表的key

简单举例子即可说明：

const data = [
{name:'小明',id:'xiaoming'},
{name:'小李',id:'xiaoli'},
{name:'小张',id:'xiaozhang'}
]

    <ul>
        {
            data.map((item,index) => <li key={index}>{item.name}</li>)
        }
    </ul>
    
    //某个事件触发，data改变了：
    const data = [
{name:'小明',id:'xiaoming'},
{name:'小王',id:'xiaowang'}, //新加入了一个
{name:'小李',id:'xiaoli'},
{name:'小张',id:'xiaozhang'}
]

原来小李和小张的key是2、3，列表改变新加入小王后，小李和小张key变成了3、4

这样diff算法会先删掉小李、小张，然后再按顺序加入小王、小李、小张。

如果采用id的形式，diff算法通过id计算发现小王是新增加的，小李小张只是位置变化了一下。

这样小李小张就不用删除，节省了删除再加入的这一步操作

这是一个简单例子，如果相对复杂的列表用index作为key更加适得其反。