Webpack构建内存泄漏表现为“FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed”，排查需先提堆内存上限验证，再用Chrome DevTools抓取对比堆快照，重点检查ts-loader、多entry、Babel重复配置及source-map，修复策略包括启用transpileOnly、动态import、去重preset、禁用生产source-map。
Webpack 构建失败若由内存泄漏引发，通常表现为 FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory，尤其在添加新 entry、启用复杂插件或处理大型 TypeScript 项目时高频出现。关键不是等崩溃再救火，而是建立可复现、可度量的排查路径。
确认是否真是内存问题
先排除干扰项，避免误判：
- 执行
node --max-old-space-size=4096 node_modules/webpack/bin/webpack.js --config ./webpack.config.prod.js—— 手动提升 Node 堆内存上限（如设为 4GB），若构建成功，基本锁定内存不足 - 对比构建前后内存占用：用
process.memoryUsage()或系统监控工具（如 macOS Activity Monitor / Windows Task Manager）观察 Node 进程 RSS 是否持续飙升且不回落 - 检查是否新增了高开销配置：比如多 entry、未 exclude 的 node_modules、重复加载的 Babel 插件、或未关闭 source-map 的 production 构建
定位泄漏源头的三步法
不靠猜，靠数据：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
-
加参数启动构建：运行
NODE_OPTIONS="--inspect --expose-gc" npm run build，然后打开 Chrome 访问chrome://inspect→ 点击 “Open dedicated DevTools for Node” → 切到 Memory 面板 → 点击 “Take Heap Snapshot”（建议在构建卡住或报错前抓取） -
比对快照差异：连续抓取 2–3 次快照，用 “Comparison” 视图筛选增长最多的构造函数（重点关注
SourceNode、Module、Parser、TSESTree等 Webpack 或 TS 相关类） -
查配置敏感点：重点检查 ts-loader 是否启用了
transpileOnly: false（默认开启类型检查，会创建大量 Program 实例）；babel-loader 是否误配了重复 preset；HtmlWebpackPlugin 是否为每个 entry 生成独立 template 实例
针对性修复策略
常见泄漏场景与对应解法：
-
ts-loader 缓存失控：在 webpack config 中设置
transpileOnly: true，并搭配 fork-ts-checker-webpack-plugin 做类型检查分离 - 多 entry 导致 AST 复制爆炸：避免为每个 report 页面单独写 entry；改用动态 import + code splitting，或统一入口 + query 参数路由
- Babel 插件重复注册：检查 .babelrc 和 webpack rules 中是否同时声明了 @babel/preset-env，移除冗余配置，确保只有一处生效
-
source-map 未压缩：生产环境禁用
devtool: 'source-map'，改用devtool: 'hidden-source-map'或完全关闭
长期防控机制
把内存监控变成 CI 环节的一部分：
- 在 package.json scripts 中加入内存基准命令：
"build:mem": "node --max-old-space-size=2048 --experimental-vm-modules node_modules/webpack/bin/webpack.js --progress" - 用
memory-fs替代真实文件写入做 dry-run 测试，大幅降低内存压力 - 对大型项目启用 Webpack 的
cache: { type: 'filesystem' }，但注意清理策略（避免 cache 文件夹无限膨胀）
