Webpack 5 相比之前的版本，在构建过程的可观测性上做了大量增强。很多团队面临的问题是：构建明明很慢，却说不清时间花在了哪里；产物体积超标，却不知道是哪个模块贡献了大部分字节数。行为分析（Behavioral Analytics）相关的配置和工具链，正是为了解决这类“黑盒构建”的问题而存在的。它通过 stats 统计输出、进度追踪、依赖图分析等手段，把构建过程中每个阶段的行为数据暴露出来，让优化工作有据可依。
一、stats 配置：构建行为数据的第一手来源
stats 是 Webpack 配置中最容易被忽视、却信息量最大的一个选项。它控制的是构建结束时终端里输出的那份统计报告。默认情况下，stats 处于普通级别，只输出入口、产物名称和警告错误。但对于行为分析而言，我们需要更细粒度的控制。
Webpack 5 对 stats 做了对象化的重构，常用的配置项如下：
module.exports = {
stats: {
all: false, // 关闭所有默认输出
assets: true, // 输出产物列表及体积
modules: true, // 输出模块信息
moduleAssets: true, // 显示模块引入的资源
reasons: true, // 显示模块被引入的原因（关键）
children: true, // 显示子编译信息
timings: true, // 显示各阶段耗时
errors: true,
warnings: true,
errorsCount: true,
warningsCount: true
}
};其中 reasons: true 是定位重复打包问题的利器。开启后，每个模块的输出会附带一段说明，指明它是因为哪个入口、哪条 import 链路被打进来的。当你发现同一个类库出现在多个 chunk 中时，翻看 reasons 就能找到引入源头。
另一个值得关注的字段是 timings。它会把构建拆成几个阶段分别计时，比如工厂阶段、优化阶段、发射产物阶段。如果优化阶段耗时异常，通常是 Tree Shaking 或者代码压缩的配置有问题；如果工厂阶段占比高，说明模块解析和 loader 转换才是瓶颈，应该从 loader 缓存和别名解析入手。
二、进度追踪与 Hook 埋点：实时观察构建行为
stats 是事后的报告，而要实时了解构建进展，需要借助进度插件。Webpack 5 内置的 ProgressPlugin 会在每次模块处理时触发回调，你可以用它做自定义埋点：
const webpack = require('webpack');
const plugin = new webpack.ProgressPlugin((percentage, message, module) => {
// percentage 是 0 到 1 的进度值
// message 是当前阶段描述，比如 "building module"
// module 是正在处理的模块路径
process.stdout.write(`\r进度: ${(percentage * 100).toFixed(1)}% - ${message} ${module || ''}`);
});
module.exports = {
plugins: [plugin]
};这段代码会把进度实时刷新在终端上。更有价值的用法是记录每个模块的处理时刻，从而统计出处理耗时最长的前若干个模块。实践中，某团队曾发现一个体积不大的 SVG 图标文件因为走了复杂的 loader 链，单个文件处理耗时接近两秒，这类问题肉眼很难察觉，只有靠埋点数据才能暴露。
如果需要更深层的控制，Webpack 的编译器本身暴露了大量 Hook，比如 compilation.hooks.buildModule 和 compilation.hooks.succeedModule。在这两个 Hook 之间记录时间差，就能精确到单个模块的构建耗时，配合一个简单的排序输出，就形成了一套自研的构建性能分析器。
三、产物体积分析与依赖图可视化
行为分析的另一个重要维度是产物体积。stats 输出的 JSON 数据可以被专门的分析工具消费，最常用的做法是把 stats 序列化成文件：
webpack --json=stats.json # 或者使用 webpack-bundle-analyzer 直接可视化 npx webpack-bundle-analyzer stats.json dist
webpack-bundle-analyzer 会生成一个可交互的矩形树图，每个矩形代表一个模块，面积与体积成正比。通过它经常能发现几类典型问题：一是 moment.js 这类库把所有语言的 locale 文件全部打包进来，需要用 ContextReplacementPlugin 砍掉；二是某些依赖被多个 chunk 重复引入，需要配置 splitChunks.cacheGroups 强制抽取公共模块；三是被 Tree Shaking 漏掉的死代码，往往是因为副作用标记缺失，需要在 package.json 中补充 sideEffects 字段。
除了体积，依赖关系也值得关注。使用 webpack --profile --json 生成的数据中包含每个模块的 issuer 字段，即“谁引入了我”。把所有 issuer 关系串起来就是完整的依赖图。借助 pyjs 或在线图谱工具渲染后，可以直观看到是否存在循环依赖、是否存在绕远路的间接引用。循环依赖在运行时不一定报错，但会导致模块初始化顺序不确定，是隐蔽的线上问题来源，通过依赖图提前排查成本要低得多。
四、把分析结论落地为优化动作
分析只是手段，最终要落到配置调整上。综合上面的方法，常见的优化路径包括：针对耗时集中在 loader 转换的场景，开启 cache: { type: 'filesystem' } 让二次构建直接复用磁盘缓存，通常能把增量构建时间压缩到原来的三分之一以下；针对模块解析慢的问题，配置 resolve.extensions 时把高频后缀放在前面，减少试探性解析的次数。
体积层面的优化则要依据分析报告逐项处理：公共依赖抽取到独立 chunk、按路由做动态 import、把大型工具库替换为按需加载的替代品。每次调整后重新生成 stats 做对比，观察字节数和耗时的变化。这种数据闭环的工作方式，比盲目照搬网上的优化清单可靠得多，因为每个项目的依赖结构不同，通用的优化建议未必适用于你的代码库。
建议把构建分析纳入持续集成流程，在每次构建时自动产出 stats 报告并归档。当某次提交导致构建时间或产物体积出现异常波动时，报告会第一时间给出线索，避免问题累积到难以排查的地步。行为分析的价值不在于一次性的诊断，而在于长期的趋势监控，让构建系统的健康状态始终处于可视范围之内。