webpack-bundle-analyzer通过可视化暴露重复打包的依赖，核心步骤是先在构建中启用插件展示模块分布，再在分析界面搜索包名、观察多节点高亮及跨chunk路径复现，最后结合引入方式（ESM/CJS混用、版本分裂、未统一alias等）针对性修复。
用 webpack-bundle-analyzer 可视化排查重复捆绑，核心是“先暴露、再定位、后修复”——它不自动解决问题，但能精准指出哪个依赖被多次打包、在哪几个 chunk 里出现、占多大体积。
快速安装与启用分析报告
在项目中安装插件并注入构建流程：
- 安装：运行
npm install --save-dev webpack-bundle-analyzer（或 yarn add -D webpack-bundle-analyzer） - 配置：在 webpack 配置（如
webpack.config.js或vue.config.js）的plugins数组中加入：
plugins: [new BundleAnalyzerPlugin({ analyzerMode: 'server', openAnalyzer: true })]
执行生产打包命令（如 npm run build），插件会自动启动本地服务（默认 http://127.0.0.1:8888），打开交互式依赖图谱。
识别重复依赖的关键操作
在可视化界面中重点关注三类线索：
-
搜索框输入包名（如
md5、lodash、moment），观察右侧是否高亮多个节点；每个高亮块代表一次独立打包实例 -
查看左侧模块树中的同名路径：比如
node_modules/md5/md5.js出现在chunk-vendors.js、chunk-home.js、chunk-admin.js三个位置，说明被不同入口/模块各自引入 - 对比文件尺寸与 gzip 后大小：若某依赖在多个 chunk 中都占几百 KB，且 gzip 后仍明显偏大，基本可判定为重复嵌入
确认重复成因的典型场景
可视化结果背后往往对应这几类引入问题：
- 不同子模块直接
import 'xxx'，而该包未被设为 externals 或统一 alias，导致 Webpack 分别解析为独立模块 - 依赖库内部引用了不同版本的同一基础包（如 A 库用 lodash@4.17.10，B 库用 lodash@4.17.21），造成版本分裂
- ESM 和 CommonJS 混用：某些包（如早期
md5）只导出module.exports，但项目中同时存在import md5 from 'md5'和require('md5')，Webpack 无法合并二者 - 动态导入（
import()）未做静态分析，导致相同包在多个异步 chunk 中被重复打包
针对性修复策略
根据成因选择对应解法，而非盲目加 alias：
- 对纯 CommonJS 包（如老版
md5），禁用 ESM 解析：resolve: { fullySpecified: false }，避免因模块格式差异拆分成多份 - 统一版本：用
npm ls xxx查清所有版本，通过resolutions（yarn）或overrides（npm v8.3+）强制收敛 - 设置 resolve.alias 仅对明确路径有效（如
md5: path.resolve(__dirname, 'node_modules/md5/md5.js')），但需确保所有引用方式一致（全用 import 或全用 require） - 对高频共享包（如
lodash、dayjs），考虑配置splitChunks.chunks: 'all'+name: 'vendor'，让 Webpack 自动提取到单独 chunk
