前言
本人之前是个对内存泄漏这一块毫无所知的菜鸟(虽然现在也只能说刚入门)。
首先是测试说这个系统点着点着就会出现崩溃的情况，说出现概率很频繁，然而我在本地和同事拼命点击也并未复现，一开始并未在意(其实是电脑配置不一样，我们电脑内存大一些)，测试说每次崩溃的时候看任务管理器内存占了三个多G，查询图表如果数据量大的话内存飙升而且降不下来。
无厘头找原因
基于这个我开始了排查之路，首先我想这个内存降不下来应该是图表那里有内存泄漏，网上查了查内存泄漏可能是因为意外的全局变量、没有移除的监听器等等...
刚好图表的那几个页面里初始化图表很多变量用了var（这个图表是以前的老代码），还有没有移除的监听器，大喜，这不就是刚好对应上了嘛，全部改掉，然后在边点击边观察任务管理器chrome占用的内存(这方法其实不对)，发现是有些改变，但还是内存有增长。而且发现切换页面的时候内存也有增长，很频繁的时候内存暴涨。但我只观察了任务管理器，完全找不到方法不知道是哪里的原因，只能瞎改。
内存泄漏排查
其实怀疑有内存泄漏的话，得用谷歌的工具面板来进行分析，任务管理器不好定位问题而且还有其他干扰项。
一、性能选项卡
首先打开chrome的无痕模式，屏蔽其他的干扰。按F12打开开发者工具，选择性能，首先点击"回收垃圾图标"(小扫把)，然后点击开始录制，在页面上进行一系列操作，然后停止录制，如果看到内存资源是持续上升的话，那么就存在内存泄漏的风险，需要进一步去分析。正常的不存在泄漏的情况下内存应该是有升有降的。
我这个就内存就一直在上升
二、内存选项卡
2.1 时间轴上的分配插桩
然后进一步分析，选择内存下面的"时间轴上的分配插桩"，先点击"回收垃圾"，然后开始录制、开始操作，小蓝条代表没有被回收的。结束录制后，点击小蓝条，可以看具体情况(但我这个没分析出来是什么造成内存泄漏的)
2.2 堆快照
选择堆快照，点击回收垃圾，在初始页面点击录制，等录制完毕之后进行一系列怀疑会出现内存泄漏页面操作，然后回到此页面，点击录制，再次进行操作、回到此页面、录制(这个过程多次进行)，之后可以看到多个快照，看内存是否有明显增长，像我这个是有明显增长的。
可以选择"比较"来对比两次快照，看"新对象数"、"已删除项"、"增量"，看有哪些新增了但没删除的，有可能就是内存泄漏的元凶，可以搜索detached，这和dom元素有关，可能是dom元素没有销毁，可能在哪里被引用了没被释放掉。
console.log()也会造成内存泄漏！！！因此生产环境要屏蔽掉这个。
点击某一项，下面会出现对应的信息，鼠标悬浮一会儿会出现对应的信息(但我没看懂)
我看到有很多和dom元素相关的没有被释放掉，而且还有很多element-plus的组件也一直存在，就像是页面切换的时候上个页面的组件都没有被卸载掉，但我并没做什么特殊操作页面也就是简单的查询列表数据，怎么会出现这样的情况？
三、查issue
百度也没找到相关的问题，自认为代码也没有问题，突然想到了去官方看看。
这个系统的框架使用的是若依的前后端分离版vue3版本，去若依的gitee上看了issue，也有这个问题，但没有解决方案，看到有人提到了vue3的issue。
去了vue的github搜索发现，有人也遇到了这样的问题！
但答案是说生产环境不会有这样的问题，开发环境因为有东西开放出来了所以会存在这些dom的问题，然而我这边的问题是开发生产都存在。
是不是版本问题呢？因此使用vite新建了一个vue3的demo，发现是开发存在内存泄漏生产不存在。而这个demo的vue版本为"^3.4.21"，我们系统vue版本为"3.2.45"，版本不一致，当即升级了vue版本，升级完之后在开发环境还存在这个问题，但生产不存在了，内存有升有降。 页面切换不存在内存泄漏了，但是echarts图表还是存在，后来发现一个图表中有各种对象的引用，可能是这些引用造成了图表没有完全销毁，进行了无用引用的删除之后，图表的内存增长正常。
但是数据量普通的图表正常，数据量大的图表还是存在内存泄漏，当数据量大的时候感觉没有销毁完全，查询了echarts的issue发现这是很久很久之前就有人提出且一直有人提出，但截至目前好像一直没有解决掉。
结语
其实还是存在一点的内存泄漏，页面切换特别频繁(不断切换)的情况下，内存还是有几兆的增长(不知道是不是正常的)，图表数据量大的情况下销毁不完全。
但是总体内存还是有升有降，在普通点击频率下应该是不会再到崩溃的程度的。
写这篇文章主要是记录一下这个过程，免得之后又给忘了，记性不太好，好记性不如烂笔头。
另外如果遇到问题，多看官方的issue，以前也这么提醒过自己，但是遇事情总是百度，百度没有就无头绪了，这不可行，多看看issue！！！ 好啦，记录完毕，未来加油！