vue优化指南（更新中）

一、使用v-for遍历时绑定的key值不建议使用index或随机数（涉及到diff算法查看）：

使用index或者随机数时的key值是不可定的，随时可能发生变化，做不到key值专一性，除了会导致bug外，也会消耗性能。

处理建议：可用后台请求数据的id值或自定义key值。

二、处理好“死”数据：

“死”数据就是不需要参与响应变化的数据。vue有部分数据是不会发生变化的自定义数据，把这些数据放在data中，每次data更新仍然会“处理”下这些“死”数据，造成不必要的资源浪费。那么如何在响应发生时跳过这些“死”数据呢？

处理建议：　　1、将“死”数据定义在data之外；　　2、使用Object.freeze(）冻结对象 => return { list: Object.freeze({xxxxxxxxxxxxxxxxxxxxxxxx})

三、合理使用computed：

在我们处理/计算变量值时，使用mothods也能实现，为什么还要用computed呢？

解释：computed有缓存机制，当conputed依赖的变量未发生变化时是不会再次执行的，可以节约资源。

四、不建议v-for和v-if同时存在：

一般，使用一个for遍历数组，发现数组中某个元素我们不需要操作渲染，就直接在for旁边写一个v-if判断元素成不成立在确定是否渲染。当然此举是可以达成我们需要的效果的。但是，内部其实已经增加了无用的操作造成了的资源浪费。

有人觉得：v-for执行一次，拿到一个元素就判断一个元素这样子怎么会浪费？其实不然，v-for的优先级是高于v-if，是要先等v-for全部遍历完毕后再执行v-if，此时我们所不需要的元素其实已经渲染了，看不到只不过是被后来的判断处理了，虽然不影响操作性，其实内部增加了无用dom操作。

处理建议：既然for在if之前就执行了，那么我们就赶在for之前决定需要渲染哪些元素不就行了。这里就用到了上面的conputed了。

比如

{{item}}

{{item}}

优化：

{{item}}

　　　　computed : {

　　　　　　arr (){

　　　　　　　　return [1,2,3,4,5].filter(item=>item != 3);

 五、灵活使用v-if与v-show：

解释：v-if是通过对dom元素的创建与删除实现视觉显隐，而v-show是通过控制元素css：display实现视觉显隐。v-if每次触发都会重跑一遍生命周期，所以需要频繁显隐某个元素时使用v-show是可以节省性能消耗的。但是也不要觉得既然v-show节省性能消耗，那都用v-show不就好了？其实不然，在页面创建时，v-if可以直接决定那些元素不需要被创建，而使用v-show则是创建后隐藏，这样比较又变成使用v-if更加节省性能消耗了。如此，要学会灵活使用才是。

六、页面内容过多时使用组件实现局部更新数据：

官方举例：在一个长列表中，如果每个item都有一个点赞按钮，点击后点赞数字+1，此时点赞组件必须是一个单独引用的组件，才能做到差量数据更新。否则会造成整个列表数据重载。

七、三个减少，一个避免：

1、减少一次渲染的节点数量：页面初始化时，逻辑层如果一次性向视图层传递很大的数据，使视图层一次性渲染大量节点，可能造成通讯变慢、页面切换卡顿，所以建议以局部更新页面的方式渲染页面。（列表分页等）

2、减少组件数量：有些nvue页面在Android低端机上初次渲染时，会看到从上到下的渲染过程，这往往都是因为组件过多导致的。每个组件渲染时都会触发一次通信，太多组件就会阻塞通信。

3、减少节点嵌套层级：深层嵌套的节点在页面初始化构建时往往需要更多的内存占用，并且在遍历节点时也会更慢些，所以建议减少深层的节点嵌套。

4、避免视图层和逻辑层频繁进行通讯：比如需要监听页面滚动，不作处理每次滚动都会监听触发视图层向逻辑层通讯。改变 scroll-top/scroll-left 时，逻辑层又向视图层通讯，这样就可能造成通讯卡顿。

参考文章：

1、林三心 ——《「自我检验」熬夜总结50个Vue知识点，全都会你就是神！！！》 查看

自我理解总结，欢迎批评指正。