SourceMap 并非内存杀手，但在大型项目中会因映射节点爆炸、sourcesContent 全量加载及 VLQ 编码开销导致内存雪崩；应通过选用 cheap 模式、禁用 sourcesContent、分阶段生成及提限 Node 内存来优化。
SourceMap 本身不是“内存杀手”，但在大型项目打包时，它会显著放大内存压力——尤其当构建工具（如 Webpack、Vite）在生成高精度 SourceMap 的过程中，需要在内存中维护海量映射节点（SourceNode）、原始源码内容（sourcesContent）和复杂编码后的 mappings 字符串时，极易触发 V8 堆内存耗尽。
为什么 SourceMap 会让内存雪崩？
大型项目（如 10k+ 行 TS + 数百个模块 + 多层依赖）生成 SourceMap 时，核心内存消耗来自三方面：
- 映射节点爆炸式增长：每个语句、变量声明、甚至 JSX 元素都可能生成独立的 SourceNode。10 万行源码可能产生百万级映射节点，全部驻留内存
-
sourcesContent 全量加载：若配置含
devtool: 'source-map'或'inline-source-map'，Webpack 默认把所有源文件内容（.ts/.jsx/.vue）读入内存并存入 .map 的sourcesContent字段，单项目轻松吃掉 1–2GB - mappings 编码过程高开销：VLQ 编码需反复字符串拼接与状态跟踪，配合 source-map 库的递归解析，在老生代堆中产生大量中间对象，GC 频繁但回收不及时
按需控制 SourceMap 规模的配置策略
不关 SourceMap，而是选对类型、裁剪内容、分阶段生成——这才是兼顾调试能力与构建稳定性的关键。
-
优先使用 cheap 模式：用
devtool: 'cheap-module-source-map'（Webpack）或build.sourcemap: 'hidden'（Vite）。它跳过列映射、不包含 loader 处理前的源码，内存占用可降 40–60% -
禁用 sourcesContent：显式关闭原始内容内联：
Webpack：devtool: 'source-map'→ 改为devtool: 'source-map'并加配置：optimization.devtoolOptions = { module: true, exclude: /node_modules/, sourcesContent: false }
Vite：build.sourcemap = 'true'→ 改为build.sourcemap = 'hidden'并在resolve.alias中避免误引大文件 -
生产环境按需生成：开发用
eval-cheap-module-source-map（快且省内存），CI/CD 构建只在出问题版本才开启完整source-map，其他一律用hidden-source-map（生成 .map 但不注入注释，调试时手动加载） -
拆分 SourceMap 输出：Webpack 5+ 可启用
devtool: 'source-map'+output.devtoolNamespace = 'myapp'，配合splitChunks让每个 chunk 单独生成 .map，避免单文件超大 mappings 导致 OOM
配合构建内存提限的兜底操作
即使优化了 SourceMap，超大型项目仍建议叠加 Node.js 内存限制调整，避免偶发峰值击穿：
- 修改
package.json构建脚本："build": "node --max-old-space-size=6144 node_modules/webpack/bin/webpack.js --config webpack.config.prod.js"
（6144 = 6GB，适合 16GB 内存机器） - Vite 项目同理：
"build": "node --max-old-space-size=4096 vite build" - 注意：不要全局设
NODE_OPTIONS，否则可能干扰本地开发服务器或其他 CLI 工具
