Loading... ## 前言 很久没有写博客了，原因主要是要考试了，闭关修炼中。。。。。。 本来我该继续闭关修炼，不理会博客日志的，但咱遇见了公司上面的神奇事儿，所以说就更新了这篇日志，记录一下排查思路和排查过程。 ## 运行失败，内存溢出 公司上面有个老项目需要搭把手，就被抓去救火了。但项目运行不起来，**内存溢出**，而且很奇怪，只有我的电脑有这个问题，其他人都没有问题。就得想办法让项目跑起来。（注意哈，**是内存溢出，不是内存泄漏**） (lll￢ω￢)  这种情况虽然是第一次见到，但可以通过修改`node`内存限制`--max-old-space-size=XX`(单位MB)来修改内存使用上限，就像这样：  如果使用其他整合框架，就看看整合框架有没有对应的配置 ## 还是溢出，开始排查 修改成`8G`内存还是溢出，所以说我怀疑某个地方是否是写了死循环。  排查方向就分为两部分**webpack**架构和每一个单页面配置（因为项目是多个单页面架构） ### webpack框架(目标不在此) 根据现有结构，将所有单页面配置全部注释，自己额外写一个单页面，能运行，webpack没有问题。  ### 逐一调查每个单页面(发现头绪) 多个单页面也不多，十多个一个一个排查就可以了，最后找到一个单页面出现内存溢出现象，再细化位置，找到了异常点。  这里出现了死循环，就会一直持续不断的使用内存。 ### 最后结论：恶意代码 现在回到开头，为什么我运行项目会内存溢出，其他人正常。因为我`clone`的项目，包都是现下的，就下到**最新的有问题的包**，而其他人还在用**上一个小版本**，所以说咱运行时内存溢出了。   在私有依赖仓库里面找到版本，通知管理员删除问题版本，ok，咱继续救火去了。 ## 后话 还好这个是私有依赖，没有放在npm/github上面，并且只影响这个项目启动，不影响实际生产。但咱还是得说说，加入恶意代码这个行为不地道啊。  最后修改：2024 年 11 月 27 日 © 允许规范转载 赞 0 如果觉得我的文章对你有用，请随意赞赏