webpack-bundle-analyzer通过解析stats.json生成可视化体积与依赖图，基于实际打包产物反向还原模块构成，推荐在生产构建中启用；配置后启动本地服务展示文件→chunk→模块三层结构，支持按parsed/gzip大小分析、关键词搜索及二次分析。
webpack-bundle-analyzer 通过解析 Webpack 打包生成的 stats.json 文件，构建模块体积树状图和依赖关系图，直观暴露体积分布与冗余问题。它不直接分析源码，而是基于实际打包产物（如 dist/*.js）反向还原模块构成，因此结果真实、可落地。
配置插件生成交互式报告
推荐在生产构建中启用，避免开发模式干扰：
- 安装：
npm install --save-dev webpack-bundle-analyzer - 在 webpack 生产配置（如
webpack.prod.js）的plugins中加入：
module.exports = {
plugins: [
new BundleAnalyzerPlugin({
analyzerMode: 'server', // 启动本地服务，便于实时刷新
analyzerPort: 8888,
openAnalyzer: true, // 自动打开 http://localhost:8888
generateStatsFile: true, // 同时输出 stats.json，供后续脚本或 CI 使用
statsFilename: 'stats.json'
})
]
};
运行 npx webpack --config webpack.prod.js 后，浏览器会自动打开可视化界面，呈现三层结构：文件 → chunk → 模块。
看懂图表定位核心问题
默认视图是「parsed size」（模块解析后大小），这是最贴近实际传输体积的参考值（比原始字节更准确，已剔除注释、空格等）：
-
顶部大色块：代表单个 bundle 文件（如
main.js），面积越大说明体积越重 - 内部嵌套矩形：每个矩形是一个模块，面积正比于其 parsed size；鼠标悬停显示完整路径、大小、gzip 后尺寸
-
重复依赖高亮：相同库（如两个
lodash版本）出现在不同 chunk 中，会被并列展示，颜色相近但位置分离——这就是“多份副本”的信号 -
深色孤立大模块：比如一个 800KB 的
node_modules/monaco-editor占满整个区块，说明它未被拆分或懒加载，是优先优化目标
结合常见问题快速响应
图表不是终点，而是诊断起点。看到异常后，立刻对应到具体优化动作：
- 某 UI 库（如
ant-design）体积过大 → 检查是否按需引入，确认 babel-plugin-import 配置生效 -
moment.js占比突出 → 替换为轻量方案（dayjs+ 插件）或用ignorePlugin剔除无用 locale - 多个 chunk 都含相同工具函数 → 启用
splitChunks.chunks: 'all'+name: 'vendors'提取公共依赖 - 某个业务模块（如
report/index.js）异常庞大 → 拆分为子模块，用import()动态导入非首屏内容 - 图片资源未压缩就打进 JS → 改用
image-minimizer-webpack-plugin，设置loader: 'responsive-loader'或转为 CDN 引用
进阶技巧提升分析效率
仅靠默认图表可能遗漏细节，建议补充以下操作：
- 点击右上角「Toggle modules」切换查看「stat」「parsed」「gzip」三种尺寸，重点关注 gzip 后大小（更接近真实网络传输量）
- 在搜索框输入关键词（如
lodash、pdf），快速定位所有相关模块及其分布位置 - 导出
stats.json，用社区脚本（如source-map-explorer）做二次分析，识别未被 tree-shaking 清理的死代码 - 配合
speed-measure-webpack-plugin一起使用：先看谁打包慢，再看谁体积大，双维度锁定瓶颈
