模块打包体积分析工具是现代前端工程化中不可或缺的一环，它们帮助开发者洞察构建产物的构成，识别并消除冗余代码，从而有效控制应用体积，提升加载性能。

核心分析工具介绍

目前主流的打包工具都集成了或拥有丰富的插件生态来支持体积分析。Webpack 作为广泛使用的构建工具，其分析方案最为成熟。

Webpack-bundle-analyzer 是最经典的可视化分析工具。它会启动一个本地服务器，并生成一个交互式的树状图（Treemap），直观展示每个模块在最终打包文件中的体积占比。安装和使用非常简单：

npm install --save-dev webpack-bundle-analyzer

在 Webpack 配置文件中引入并使用：

const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;

module.exports = {
  // ... 其他配置
  plugins: [
    new BundleAnalyzerPlugin({
      analyzerMode: 'server', // 可选 'server'， 'static', 'json', 'disabled'
      generateStatsFile: true, // 是否生成 stats.json 文件
      statsOptions: { source: false }, // stats.json 文件的选项
      openAnalyzer: true, // 构建完成后自动在浏览器打开报告
    })
  ]
};

执行构建命令后，浏览器会自动打开分析页面。图中不同颜色的方块代表不同的文件，面积大小代表文件体积。你可以清晰地看到：

• 哪些第三方库（如 lodash, moment）体积过大。
• 是否有多份相同库的不同版本被打包进来。
• 你自己的业务代码模块的分布情况。

Webpack 内置的 --json 输出 是另一种基础但强大的方式。通过 webpack --profile --json=compilation-stats.json 命令，可以生成一个包含所有模块、块和依赖关系的详细 JSON 文件。这个文件可以被许多其他工具解析，例如 webpack-visualizer 或 source-map-explorer。

基于统计文件的可视化工具

除了 bundle-analyzer，还有一些工具专门用于可视化 stats.json 文件。

source-map-explorer 是一个强大的工具，它利用 Source Map 文件将打包后的代码映射回原始源代码，让你能精确地看到每一行源代码对最终 bundle 体积的贡献。这对于定位那些被意外引入的庞大依赖或未正确 Tree Shaking 的代码特别有效。

npm install -g source-map-explorer
# 假设你已生成带有 source map 的构建文件 bundle.js 和 bundle.js.map
source-map-explorer dist/bundle.js

执行命令后会生成一个可视化 HTML 页面，用区块图清晰展示了 bundle.js 中每个源文件及其具体行、列所占用的字节数。

与构建流程集成

为了持续监控体积变化，可以将分析工具集成到 CI/CD 流程中。

一种常见做法是使用 webpack-bundle-analyzer 的 generateStatsFile 选项生成 stats.json，然后在 CI 环境中使用一个轻量级插件（如 bundle-stats）来比较当前构建与基准构建（如上一次主分支构建）的差异，并输出报告或设置体积门禁。

例如，在 package.json 中配置一个分析脚本：

{
  "scripts": {
    "build": "webpack",
    "analyze": "webpack --profile --json > stats.json && bundle-stats ./stats.json --compare ./baseline-stats.json"
  }
}

bundle-stats 会生成一个对比报告，显示总体积、初始块体积、缓存无效化（通过哈希变化判断）等指标是增加还是减少，从而在合并代码前发现潜在的性能回归。

针对 Vite 和 Rollup 的生态

对于使用 Vite 或 Rollup 的项目，同样有优秀的分析工具。

rollup-plugin-visualizer 是 Rollup 生态中的首选，Vite 也直接支持。它生成多种格式的报告（Treemap, Sunburst, Network 等），帮助分析 Rollup/Vite 的打包输出。

在 vite.config.js 中配置：

import { defineConfig } from 'vite';
import visualizer from 'rollup-plugin-visualizer';

export default defineConfig({
  plugins: [
    visualizer({
      open: true, // 构建后自动打开报告
      filename: 'bundle-analysis.html', // 输出文件名
      gzipSize: true, // 同时显示 gzip 后的大小
      brotliSize: true, // 同时显示 brotli 压缩后的大小
    })
  ],
});

这个插件提供的网络图（Network）视图尤其有用，它可以模拟模块的加载顺序和依赖关系，帮助你优化异步加载和代码分割策略。

深度分析与实践案例

仅仅看到体积大小还不够，需要深入分析原因并采取行动。例如，分析报告显示 moment.js 库占了 200KB+。

1. 问题诊断：moment.js 包含所有时区数据和本地化文件，而你的应用可能只需要英文和 UTC 时间。
2. 解决方案：使用 moment-locales-webpack-plugin 来剥离未使用的语言包，或者更激进地，用轻量级的替代库如 day.js 或 date-fns 替换。

另一个常见案例是发现多个 chunks 都包含了相同的工具函数库（如 lodash）。

1. 问题诊断：这是因为在多处使用了 import _ from 'lodash'，导致每个用到它的 chunk 都打包了一份完整或部分副本。
2. 解决方案：使用 lodash-es 并进行按需导入（import map from 'lodash-es/map'），同时确保 Webpack 配置了 splitChunks 来提取公共依赖。

// webpack.config.js 优化 splitChunks
module.exports = {
  optimization: {
    splitChunks: {
      chunks: 'all',
      cacheGroups: {
        vendor: {
          test: /[\\/]node_modules[\\/]/,
          name(module) {
            // 将每个 node_modules 中的库分离到单独的 vendor 文件中
            const packageName = module.context.match(/[\\/]node_modules[\\/](.*?)([\\/]|$)/)[1];
            return `vendor.${packageName.replace('@', '')}`;
          },
        },
      },
    },
  },
};

建立性能预算与监控

最终，分析工具应该服务于性能预算。你可以在 Lighthouse CI、Bundlesize 或 webpack-bundle-analyzer 中设置体积阈值。

例如，使用 bundlesize 库在 CI 中设置门禁：

// package.json
{
  "bundlesize": [
    {
      "path": "./dist/*.js",
      "maxSize": "100 kB"
    },
    {
      "path": "./dist/*.css",
      "maxSize": "10 kB"
    }
  ]
}

在 CI 脚本中运行 npx bundlesize，如果任何文件超过 maxSize，构建将会失败，从而阻止体积过大的代码合并到主分支。这迫使开发团队在开发新功能时就必须考虑其对性能的影响，将性能优化左移，成为开发流程中自然的一部分。通过定期运行分析工具并审查报告，团队能够持续对代码库的健康度保持敏感，在应用体积缓慢增长变成性能问题之前就将其扼杀在摇篮中。