Webpack 构建阶段无法预测内存占用，因其不提供运行时内存预测能力；可替代方案是用 size-plugin 结合 gzipSize 与 AST 分析做启发式估算，并通过 CI 告警或 Puppeteer 在真实环境采集内存数据。
Webpack 构建阶段无法直接预测内存占用
不能。Webpack 本身不提供运行时内存占用预测能力，也没有官方 API 允许插件在构建过程中“预估”后续执行时的内存消耗。所谓“内存占用预测”，实际是混淆了两个不同阶段：构建阶段（compiler 运行时）和运行阶段（浏览器或 Node.js 执行打包产物时）。你在 apply(compiler) 中能拿到的是模块图、资源列表、chunk 结构等静态信息，不是 JS 引擎堆快照。
真正可落地的替代方案：用 size-plugin + 自定义钩子做体积-内存相关性建模
虽然不能预测内存，但资源体积（尤其是 gzip 后）与首屏内存压力强相关。你可以结合 size-plugin 输出和自定义逻辑做启发式估算：
-
size-plugin在done钩子中给出每个 chunk 的gzipSize，这是最稳定、可复现的代理指标 - 在
compilation.hooks.processAssets阶段，遍历compilation.assets，对 JS 文件做简易 AST 分析（例如统计new Array()、JSON.parse()调用频次），标记高内存风险模块 - 把体积数据 + 风险标记写入 JSON 文件，供 CI 脚本读取并触发告警（例如：某个 chunk gzip > 150KB 且含 >3 次
JSON.parse）
示例片段（非完整插件）：
${asset.name}
为什么不要尝试 hook Node.js V8 内存 API？
有人想在 compiler.run 前后调用 process.memoryUsage() 或 v8.getHeapStatistics() 来“测差值”。这不可靠，原因很实在：
- Webpack 启动本身就会触发大量缓存初始化、loader 编译、模板解析，这些内存波动远大于你关心的“业务代码内存特征”
-
memoryUsage().heapUsed包含了 Webpack 自身的内存开销，无法剥离 - 不同机器、Node 版本、GC 时机导致数值抖动极大，无法形成可比基线
如果你真需要运行时内存画像，得换地方做
构建阶段只负责“准备”，内存行为必须在真实执行环境里观测：
- 在目标页面中注入 PerformanceObserver 监听
measure或navigation类型，捕获performance.memory（仅 Chrome 支持） - 用 Puppeteer 启动无头 Chrome，加载打包后页面，定时抓取
browser.metrics()中的JSHeapUsedSize - 把这类采集结果回传到构建流程（例如写入
.memory-profile.json），和本次 commit 关联，实现“构建 → 部署 → 观测 → 反哺构建配置”的闭环
构建插件能做的，只是把观测点埋进去、把报告路径配好、把阈值检查跑起来——真正的内存数据，永远不在 Webpack 进程里。
