Vue项目npm run build报JS堆内存溢出，调整内存参数无效如何解决

核心触发原因 #

• 从报错栈帧可直接定位OOM的触发点：所有崩溃流程最后都指向JsonStringifier的递归序列化逻辑，说明内存耗尽不是webpack代码转译、代码压缩环节的常规高占用导致的，是构建流程中正在对一个超大、带循环引用或无限嵌套的JS对象执行JSON序列化，就算大幅提高堆内存上限，无边界的递归序列化过程最终也会撑爆内存。
• 此前传入的堆内存参数未生效的证据非常明确：报错日志中GC阶段的内存峰值仅到1.9GB，远低于设置的8GB上限。本质是参数传递路径存在偏差：npm run 命令后追加的--xxx参数会直接传给脚本执行的程序（也就是vue-cli-service），而非底层的Node运行时；vue-cli-service本身不识别内存配置类参数，会直接忽略传入的内容，Node的堆上限仍沿用默认的1.7~2GB配置，因此才会在2GB不到的位置触发内存崩溃。
• 开发服务正常运行、生产构建报错的差异逻辑：npm run serve是按需编译、模块热更新的运行模式，不需要一次性全量收集所有模块的配置元数据、生成全量资源映射；生产构建需要全量扫描所有依赖、序列化所有模块的配置表、生成产物资源映射关系，会把开发模式下不会触发的超大序列化任务全部执行一遍，自然触发内存崩溃。
• 结合项目依赖列表，额外的高危触发点包括：
  • 重复安装了3个feather图标相关包（vue-feather、vue-feather-icon、vue-feather-icons），冗余依赖会额外增加构建时的扫描和序列化开销
  • 将express、cors、connect-history-api-fallback这类纯服务端依赖放在生产依赖列表中，被webpack默认扫描纳入构建流程
  • 全量导入devextreme 19.2.6，该包全量模式下的配置元数据体积超过40MB，是构建序列化阶段的典型高内存消耗源

落地解决步骤 #

• 第一步：修正Node内存参数的传递路径，让堆内存配置真正生效
  不要把内存参数直接跟在npm run 命令后传递，修改package.json中的build脚本，直接给Node运行时传递配置：

  "scripts": {
    "build": "node --max_old_space_size=8192 ./node_modules/@vue/cli-service/bin/vue-cli-service.js build"
  }
  

  若需要跨平台兼容，可配合cross-env工具编写跨平台兼容的脚本：cross-env NODE_OPTIONS=--max_old_space_size=8192 vue-cli-service build
• 第二步：压缩依赖体积，降低构建时的扫描开销
  • 删掉3个重复的feather图标依赖中未实际使用的包，仅保留生产环境真正用到的一个图标库
  • 将express、cors、connect-history-api-fallback、express-async-errors这类纯服务端依赖从生产依赖列表中移除，避免被webpack扫描纳入构建流程
  • 将devextreme从全量导入调整为按需导入，可减少80%以上的构建内存占用
• 第三步：调整构建配置，减少序列化阶段的内存消耗
  • 在vue.config.js中关闭生产环境的sourcemap生成配置：productionSourceMap: false，sourcemap生成阶段会序列化所有源码的位置映射，是构建OOM的高发场景
  • 配置webpack的splitChunks规则，将devextreme、xlsx、jspdf这类大体积依赖拆分为独立chunk，避免所有模块的元数据被堆到同一个内存块中
  • 排查路由、Vuex、第三方插件配置中是否存在循环引用的对象，避免JSON序列化时出现无限递归
• 临时排查方法：如果完成上述调整后仍有报错，可以在构建命令中增加--profile --json参数，将构建过程的输出落地为日志文件，定位最后卡住的插件位置，针对性做优化。

内容的提问来源于stack exchange，提问作者Bopsi