webpack-bundle-analyzer是用于可视化分析Webpack打包产物体积的插件，通过读取stats.json生成交互式树状图，按parsed/gzip大小排序展示模块占比，帮助定位冗余依赖、重复引入及未优化资源，从而指导按需加载、版本统一和代码拆分等优化动作。
直接用 webpack-bundle-analyzer 打开打包产物的统计文件，就能看到所有模块按体积从大到小排列的树状图，这是调优的第一步——不是靠猜，而是靠可视化排序找“大户”。
生成可分析的 stats.json 文件
Bundle Analyzer 本身不生成打包结果，它读取 Webpack 输出的构建统计（stats）数据。确保你的构建命令能输出完整 stats：
- 在 webpack 配置中启用
stats: 'verbose'或直接使用 CLI 参数：webpack --env production --json > dist/stats.json - Vue CLI 用户推荐加环境变量方式：
NODE_ENV=production npm_config_report=true npm run build，它会自动产出stats.json - 也可以在插件中配置
generateStatsFile: true，让 BundleAnalyzerPlugin 主动写入文件
启动可视化报告并看懂体积排序
运行分析命令后，浏览器打开的交互式页面默认按“parsed size”降序排列节点，面积越大、字体越粗的模块越占体积：
- 左侧文件列表已天然按大小倒序排列，一眼锁定 top 5 大模块（比如
node_modules/lodash、ant-design-vue、某路由 chunk） - 点击某个大模块，右侧显示它的依赖树——能看清是它自己代码大，还是它引了别的大包（例如
moment被date-fns间接引入） - 注意区分
parsed（原始 JS 大小）、gzip（压缩后预估）、stat（未处理前的源码体积），优化优先盯gzip
根据排序结果做针对性拆包与剔除
排序暴露问题后，调优动作要对应到具体模块类型：
-
第三方库过大：比如整个
echarts占 1.2MB → 改用echarts-for-react的按需引入，或换轻量方案（如chart.js） - UI 组件库全量引入：Ant Design 或 Element Plus 没配 babel-plugin-import → 补上按需加载配置，再看分析图里对应组件是否消失
-
重复依赖版本：图中出现多个
lodash@4.17.21和lodash@4.18.0→ 运行npm ls lodash查冲突，用resolutions或overrides统一版本 -
非必要开发依赖混入生产包：比如
mockjs出现在 prod 构建里 → 检查 import 是否写死，改用if (process.env.NODE_ENV === 'development')包裹 -
静态资源未压缩：图片/字体文件块异常大 → 对应路径加
image-minimizer-webpack-plugin，或转 WebP
验证拆包效果是否合理
做完调整后重新构建+分析，重点看三处变化：
- 原来的大 chunk 是否被拆成多个更小、更语义化的文件（如
chunk-vendors缩小，chunk-login独立出来） - 是否产生大量 splitChunks.minSize（默认 20KB），避免 HTTP 请求激增
- 公共模块是否真正被提取：检查
chunk-commons或runtime是否稳定存在，且没把业务逻辑误打进 vendor
