记录一次前端页面崩溃的产生及处理
起因：前端的一个地图页面某一些单子一点进去，就会导致页面卡死、崩溃，浏览器最终给的错误码为：out of memory。
排查：OOM！第一反应是猜测会不会是因为地图要渲染的点位太多了（大概7、8千个点位），后面在另一个页面看到相同数量的点位也能够正常的渲染出来，就排除了这一猜测。
由于这个情况只发生测试环境，本地环境复现不出来，一时陷入了困境。后面对比了两个环境的区别，测试环境是通过打包，使用 nginx 代理的方式运行的，本地环境是通过 node 环境运行。于是本地环境也采用打包，nginx 代理的方式运行，终于成功的把页面崩溃情况复现出来。
第一次代码定位：通过查看网络请求，发现页面卡死前有个请求一直处于未返回状态，于是使用接口调试工具手动调用该接口，但该接口能正常返回，排除接口问题。接着将代码定位到发送该请求处，在进行各种各样的尝试后发现，将 statusList 从响应式类型换成非响应式类型后，居然页面不会崩溃了，于是便再发了一版测试环境…
...
<div v-for="(item, index) in statusList" :key="index" style="width: 100%">
...
</div>
...
const statusList = ref<any>();
const draw = async () => {
...
statusList.value = await getStatus();
...
}
解决方案：将响应式类型换成非响应式类型…
再起：发版没过多久，这个状况又出现了，不同之处在于，这次刚点进去没问题，过了一段时间才会出现页面崩溃的情况。
排查：这次情况第一反应，内存泄漏！通过内存工具发现，页面快照的内存会随着时间的增加而增加。这次首先去优化了地图元素的使用，没用的元素该销毁的进行销毁，不出意外，没啥效果。又是一顿各种尝试，终于发现了问题所在！
第二次代码定位：通过打 log，发现某一方法（getShipRoute）一直在死循环不断输出 log，于是定位到了该代码处。
...
<div v-for="(item, index) in statusList" :key="index" style="width: 100%">
<div v-if="getShipRoute(Number(items.pointIndex) - 1)">
...
<span class="arr-time">船名:{{ shipRoute.vesselName }}</span>
...
</div>
</div>
...
const shipRoute = ref<any>(null);
const getShipRoute = (idx:number) => {
let a = routeList.find((v: any) =>{
return v.range === idx
});
if (a) shipRoute.value = a;
return a;
}
原因：shipRoute 是一个响应式数据，内部是一个对象，第一次循环，将 a1 的引用赋值给 shipRoute，然后 shipRoute 进行第一次页面元素 pageElement1 渲染，第二次循环，将 a2 的引用赋值给 shipRoute，然后 shipRoute 进行第二次页面元素 pageElement2 渲染，同时由于 shipRoute 发生改变， pageElement1 需要重新进行一次渲染，又将 a1 的引用赋值给 shipRoute，此时 shipRoute 对于 pageElement2 来说又发生了变化，至此死循环发生了。
解决方法：将 shipRoute 的内部数据换成数组，至此该问题得到了解决。
疑问点：
- 为什么第一次改动可以延迟问题的发生？
- 为什么打包才会导致问题的发生？
对于疑问1，推测跟渲染方式有关，如果外层数组为响应式数据，每次死循环都得渲染外层整一个代码块，这无疑大大加速了内存的爆炸，而不为响应式数据，则每次死循环只需要渲染内层一个小代码块，内存增长的速度不会那么快。但随着时间的累积作用，内存也会增长到极限值进而引发崩溃，这似乎解释了为什么第一次改动可以延迟问题的发生。
对于疑问2，猜测 node 环境可能对此种情况做出了一定的优化，导致问题没能复现，具体原因也未得而知。
补充：页面崩溃前的情况：其他元素貌似渲染完毕，只剩下地图元素还没进行渲染，这一定程度误导了我们对于该问题产生原因的推测。