前言
日常开发中最怕碰到生产问题，业务逻辑问题还好，如果是白屏或者页面崩溃就得头痛起来了，前两天刚好碰到了页面崩溃问题，下面分享下解决思路。
思考
公司技术栈是vue2，项目A同事发了一张截图说是页面崩溃了，让给解决下，本来推辞到了第二天，结果快下班的时候又说必须解决，只能跟同事沟通想办法解决了。 
页面崩溃大部分情况都是内存溢出了，溢出的原因多种多样，得我们一个个分析：
- iframe嵌入 。之前做过的项目B也碰到过页面崩溃问题，当时看了好久拉了外援才发现原因。该项目是嵌入客户系统中的，每个菜单页面都是用iframe嵌入的，打开几个页面就有几个iframe，代码也没有销毁iframe的逻辑，打开的iframe一直占用着内存，最终内存溢出，页面卡死。所以我先检查了项目A的代码没发现用iframe，也没有嵌到客户系统中，因此排除掉了。
- 浏览器兼容。兼容更多表现为功能缺陷，但是项目本身依赖比较多，说不定是那个插件存在兼容问题导致页面崩溃了。兼容性排查很简单，现场用的谷歌浏览器，让同事用谷歌最新版打开项目，观察页面是否有报错，是否还会崩溃。结果页面没任何报错，依旧崩溃，暂时排除兼容性。对于API、属性的兼容性检查可以用Can I use。
- 死循环代码。在我们写循环的时候，如果判断条件错误，一直循环执行代码，变成死循环，页面一会也就崩溃了，最简单的例子。
js
for (let i = 0; i > 0; i++) {
console.log(i)
}项目A之前做过定制功能，我是接手的这个项目，就问了之前开发的同事，代码没啥问题。
- 大数据加载。当页面加载大量数据或者一次渲染太多dom也会造成页面崩溃。于是询问了同事项目有没有大文件的加载，说是没有；因为该项目用了websocket，就问了下ws推送数据量是否过大，uat环境上还没开始用ws。注意ws长连接，在每次连接结束后就会将http请求释放，所以ws不是累加占用资源的。最后，连接远程看了下，发现在某个页面的时候，内存骤加，观察了一下，发现一个接口pending时间很长。现场同事说这个接口有8w多数据，这个数据是级联框的下拉数据。页面崩溃的原因不言而喻，就是因为大数据的加载，一下返回8w多数据，前端也没做懒加载，浏览器直接罢工不干了。接口的资源加载情况我们在network下面就能看到。
经过一系列的分析，终于找到了问题原因------数据量过大。平时刷到过如果后端返回10w条数据，前端该如何处理，没想到自己还能碰到过8w多条数据。因为时间紧急，就先把对应接口去掉了，后面优化肯定要做分页加载了。
总结
以上就是页面崩溃问题的分析，如果我们碰到此问题，优先检查下代码，然后再考虑大数据加载，当然接口很多，我们要多沟通，多观察才能找到相关的接口，进一步解决问题。