写在前面
- 数据量100条左右
- Tree层级4-5级
- 节点操作卡顿时间4~5s，并伴随初始化样式失真
卡顿只存在表格内嵌树结构情况下，单独Tree组件是不存在卡顿的。卡顿原因仍在定位源码中，之所以会去排查源码是因为我用同样的数据测试element、ant-design框架均不会出现卡顿，不仅仅是无卡顿现象，另外两款框架反而非常流畅，流畅到和单独Tree组件无区别，这只能说明是iview源码设计上的性能缺陷，目前已经提交了官方issues。
解决方案
方案一：以Table数量去换渲染性能
典型的“没有什么是加一台解决不了的问题”思路。初始化后台数据进来，往往是N叉树，卡顿前为一次性往一个表格中放，加重了渲染压力，改进后为一个根节点一个Table，除顶部表头其余表格的表头全部隐藏掉。
改进后卡顿明显好转，多次测试结果性能约为改进前的3~4四倍，代码比较简单，这里就不贴了，感兴趣的可以留言。
这种方式是取巧，不能从根本上解决问题。首先只能在根节点上横向优化，如果是单根树并且数据量很大那就等于没优化，并且只能根节点上以数量代替，类似于多线程吧，但进到内层节点就不能再用了。
方案二：按需渲染，操作节点时再取这部分数据进行渲染
这个是比较好的思路，当然也有缺点：
例如当网络不佳时只能看到根节点数据，需要考虑很多网络不佳的用户友好性处理。
例如除了节点操作外，还涉及到当前树结构的信息查询，需要全部信息进行筛选也会受到影响，当然也可以让后台去数据库里查。
补充俩接口，第一个接口用来请求所有根节点，第二个接口一当前操作节点去拿子节点。
方案三：更换框架
此方案万不得已可以用，除了稍微影响项目体积之外没有副作用，可以按需引入ant-design框架中的Table组件，很多逻辑要按ant-design的API改动一下。
总体来说比较推荐方案二。当然最好的是官方优化该问题或者自己去源码上进行调整，对能力要求比较高。上述代码后续做好样例数据再补上，数据涉密不太好直接贴上来，其实开发重在思路，代码都是差不多的。
