昨天临近下班时，产品突然告诉我运营后台线上某页面进入就卡死了，一番操作没反应，稍后浏览器弹窗提示"该页面无响应"，如下图所示：

浏览器页面进入后卡死导致无法操作的原因有很多，如电脑配置过低（cpu和内存）、当前时间运行软件过多、当前浏览器主进程处理过多任务、当前页面渲染进程处理过多任务等原因。 既然知道发生时机了，那就复现下来确认问题的真伪及原因。首先通过chrome 浏览器的devtools performance的Start profiling and reload page按钮下来测下页面性能，具体性能统计截图如下：

以上可得知在性能记录时间内以下指标都居高不下：

上文看到了主线程中在重复执行某逻辑，尝试从事件调用栈出发，如下图（这里小编使用的构建工具是webpack，其devtool设置为false，但其实还是能根据经验判断出关键信息，请记得不要把关键业务数据硬编码在前端代码中）：

element-ui 2.x级联组件(面板)的源码如下，上图中主线程中的调用栈顺序与组件源码中的事件调用顺序完全匹配，而这些调用的事件就是组件加载时的初始化内部store、渲染级联元素、更新勾选状态和多选节点路径等等。

原来主线程重复执行的逻辑是级联组件组件的加载和初始化，等等！！！怎么会重复初始化(监听的options只更新一次)？此时FPS也没有值？这不是卡顿的性能记录！但为什么又出现这个样子呢？还未得知。

重新使用devtools performance的Record按钮来测试下性能，点击按钮后刷新页面，待页面可操作时停止统计。截图如下所示：

从上图可以看到在页面加载完成后(红线代表onload事件被触发)，此后很快FPS条变红，而Frames条也提示有21341ms的空闲段，代表页面卡顿但无渲染。与此同时CPU消耗也被Scripting占满，JS HEAP也被消耗至62MB，仔细观察线程占用情况，发现主线程在该时间段拥有一个级联组件的20s的长任务，可基本判断出是级联组件的初始化配置逻辑长期执行占据了主线程和运行内存，导致浏览器无暇处理用户体验，这也就出现了文章顶部的问题截图。

经过对比数据量发现，级联组件的初始化配置长期执行的原因是单个节点的直属子节点数据过多(问题出现的数据量是5000+)。

由于当前问题场景中的数据是组织架构内的员工，在现有功能实现基础上使用数据懒加载即可(数据大小1.5MB)。由于接口中数据是一次返回，需要在组件渲染层面进行数据懒加载，具体修改如下：