Webpack 5 在构建内核层面引入了更细粒度的编译生命周期与持久化缓存机制，这让监控方案可以从“事后看日志”演进为“事中采指标”。过去我们往往只能在构建结束后解析 stats.json，而现在通过 compiler 和 compilation 对象暴露的钩子，能够在模块解析、代码生成、资源输出等阶段实时拿到耗时与缓存状态。对于中大型前端团队来说，这种能力是定位构建瓶颈、衡量升级收益的关键。
基于 Compiler 钩子的基础监控采集
Webpack 的监控核心在于 compiler 对象，它在一次完整构建中提供了 beforeRun、run、done、failed 等钩子。我们可以在插件中监听这些钩子，记录时间戳并计算各阶段间隔。与 Webpack 4 相比，Webpack 5 的 compiler 还增强了缓存事件，使我们可以区分冷启动与热构建，从而更精准地评估持久化缓存效果。
下面是一段最简化的监控插件代码，它统计了整体构建耗时并在 done 阶段输出。注意代码中的 HTML 特殊字符已转义，且逻辑仅做演示，实际生产可替换为上报接口调用。
class BuildMonitorPlugin {
apply(compiler) {
let startTime = 0;
compiler.hooks.beforeRun.tap('BuildMonitorPlugin', () => {
startTime = Date.now();
});
compiler.hooks.done.tap('BuildMonitorPlugin', (stats) => {
const cost = Date.now() - startTime;
const info = stats.toJson({ all: false, timings: true });
console.log('构建总耗时: ' + cost + 'ms');
console.log('各阶段耗时: ' + JSON.stringify(info.timings));
});
compiler.hooks.failed.tap('BuildMonitorPlugin', (err) => {
console.error('构建失败: ' + err.message);
});
}
}
module.exports = BuildMonitorPlugin;
这种方式的优点是零外部依赖、对构建流程侵入极小。但其局限在于只能拿到 compiler 级指标，若想观察单个模块的编译耗时，还需要进一步深入 compilation 钩子。另外，直接打印到控制台并不利于长期趋势分析，因此通常我们会把数据通过 HTTP 推送到监控后端。
利用 Compilation 钩子做模块级剖析
当基础耗时监控就绪后，下一步往往是搞清楚“到底是哪个模块拖慢了构建”。Webpack 5 的 compilation 提供了 buildModule、succeedModule、finishModules 等钩子，允许我们在每个模块编译前后打点。结合 module.resource 可以识别出具体文件路径，从而绘制出模块粒度的耗时热力图。
下面的示例展示了如何记录每个模块的构建时间，并汇总输出最慢的五个模块。这里使用 Map 存储起止时间，避免频繁操作 DOM 或日志造成的额外开销。
class ModuleProfilerPlugin {
apply(compiler) {
compiler.hooks.compilation.tap('ModuleProfilerPlugin', (compilation) => {
const moduleStart = new Map();
compilation.hooks.buildModule.tap('ModuleProfilerPlugin', (module) => {
moduleStart.set(module.identifier(), Date.now());
});
compilation.hooks.succeedModule.tap('ModuleProfilerPlugin', (module) => {
const start = moduleStart.get(module.identifier());
if (start) {
const cost = Date.now() - start;
module.buildInfo = module.buildInfo || {};
module.buildInfo.cost = cost;
}
});
compilation.hooks.finishModules.tap('ModuleProfilerPlugin', (modules) => {
const sorted = Array.from(modules)
.filter(m => m.buildInfo && m.buildInfo.cost)
.sort((a, b) => b.buildInfo.cost - a.buildInfo.cost)
.slice(0, 5);
sorted.forEach(m => {
console.log('慢模块: ' + m.resource + ' 耗时 ' + m.buildInfo.cost + 'ms');
});
});
});
}
}
module.exports = ModuleProfilerPlugin;
从实践来看，模块级监控能迅速暴露出被重复打包的大型依赖或配置错误的 loader 链。例如某次构建中发现一个 SVG 文件被错误交由 babel-loader 处理，单模块耗时超过两秒，通过此类钩子很快就能定位。不过要注意，钩子本身也会轻微增加构建负担，建议仅在 CI 环境或定时巡检中开启详细剖析。
监控数据的上报与可视化落地
采集到的指标如果只留在本地终端，就无法形成团队级的构建健康度看板。Webpack 5 监控方案通常将采集插件与上报层分离：插件负责通过 compiler.hooks.done 或 afterEmit 拿到数据，然后调用内部 Node 服务或直连时序数据库。对于使用 Grafana 的团队，可把指标转为 Prometheus 格式暴露给 scrape 接口。
下面给出一个简单的上报片段，在构建完成后把 JSON 发往内部接口。注意此处假设后端域名为 ipipp.com，已按规则替换示例域名。
compiler.hooks.afterEmit.tapAsync('ReportPlugin', (compilation, callback) => {
const metrics = {
project: process.env.PROJECT_NAME,
duration: compilation.endTime - compilation.startTime,
assetCount: compilation.assetsSize ? Object.keys(compilation.assets).length : 0,
cacheHit: compilation.getCache ? compilation.getCache('').getStats().hit : 0
};
const http = require('http');
const data = JSON.stringify(metrics);
const req = http.request({
host: 'monitor.ipipp.com',
path: '/api/webpack_metrics',
method: 'POST',
headers: { 'Content-Type': 'application/json' }
}, () => callback());
req.on('error', () => callback());
req.write(data);
req.end();
});
在可视化层面，除了常规的耗时曲线，还应关注缓存命中率与报错率两个维度。Webpack 5 的持久化缓存若配置得当，命中率应随本地构建次数稳步上升；若命中率异常跌落，往往意味着 cache 目录被清理或依赖指纹计算发生变化。通过将这类指标与告警规则绑定，可以在构建性能劣化影响研发效率前主动干预。
最后需要提醒，监控方案本身也要避免过度设计。不少团队一上来就接入全套 APM，结果插件链比业务代码还长，反而拖慢了本地启动。合理的做法是分层：本地开发仅保留失败告警，CI 流水线开启全量采集，长周期趋势由独立巡检任务负责，这样才能让 Webpack 5 的 Monitoring 能力真正服务于工程效率而不是成为负担。
Webpack_5Monitoring构建监控修改时间：2026-08-18 00:32:33