Jin
## 背景 stalar电商平台是公司2020年的新业务，目标市场主要是中东五国，主要技术栈为nuxt。一次常规需求上线后，偶然打开了chrome memory面板，打了几个内存快照，发现内存一直在涨，且无论跳转到什么页面，内存都稳定增长；为排除干扰因素，再快照前手动点击了gc，发现内存的增量仅仅下降了一点点，总体还是呈稳定增长趋势。意识到这是一个比较严重的问题，因为商详页面是有推荐商品模块的，也就是说用户的浏览路径在这里是没有尽头的，很有可能已经有用户出现在浏览大量商品后出现页面崩溃或者浏览器闪退的情况了(目前还缺乏页面崩溃监控，所以还不能确定)。 下图的内存快照，第一张是第一次进入商详页，第二张是在商详页中点击推荐商品进入下一张商详页，重复十次(下文比对内存等变化的截图全部采用这种方式)。 两次生成快照前都手动点击了gc，可以看到内存张了12.3MB  ## 原因排查 ### nuxt框架问题 观察发现任意页面的跳转，都会让内存稳定增长，即使是一些没有什么逻辑的简单页面，也有一定程度上的内存泄漏，所以首先怀疑nuxt框架或者依赖的其它轮子本身存在着内存泄漏的问题，google了一下发现nuxt的某些小版本确实存在内存泄漏问题，比如: [nuxt/issue/7855](https://github.com/nuxt/nuxt.js/issues/7855) 既然怀疑框架有问题，首先做的就是将nuxt升级到最新版本(其实我们用的nuxt版本已经比较新了，看nuxt的一些issue貌似是一些小版本有跳跃性的内存问题，比较迷惑)，观察发现情况仅仅好转了一点，对于一些简单页面，内存已经不怎么增长了，但是重灾区商详页，还是能看到大幅度内存增长。 ### 代码问题 排除掉框架的影响，回到chrome分析内存泄漏的原因，重新打开商详页并打开`performance monitor`，重复上文的从商详页点击推荐商品操作，发现`JS heep size`、`DOM Nodes、JS`、`event listenters`这三项都在稳定增长，同样跳转10次，`DOM Nodes`从3k左右上涨到了11k，下图为跳转10次后的`performance monitor`面板截图:  同样是商详页，即使不同商品页面元素有差异，`DOM Nodes`也不可能有如此巨大的差异，`event listenters`也有稳定增长，所以怀疑是一些`DOM`的事件监听没有解绑，导致游离节点一直没有释放，再比较下上文打的两张内存快照，发现确实有非常大的`detached node`增长，印证了这个猜测。 ...
jQuery mobile框架中使用轮播图插件，如果在两个不同的data-role=“page”中分别使用两个轮播图，只有一个正常，另外一个轮播会有问题