Bundle-Buddy logo

Bundle-Buddy

通过分析 Source Map 检测 JavaScript 多 chunk 之间重复代码的可视化工具

Bundle分析性能优化Source Map代码重复检测

一个基于 Source Map 的可视化工具，用于检测多个 chunk 之间的源代码重复，帮助开发者发现 code splitting 策略中隐藏的冗余模块，支持 Webpack、Rollup、esbuild 等任意打包器。

访问官网

Bundle-Buddy

一个通过分析 Source Map 检测 JavaScript 多 chunk 之间重复代码的可视化工具——帮你发现 code splitting 策略中隐藏的冗余模块。

技术简介说明

bundle-buddy 是一个用于理解和优化 JavaScript bundle 体积的工具，核心定位是检测多个 chunk 之间的源代码重复。在现代前端开发中，为了加快首屏加载速度，开发者通常会使用 code splitting 将应用拆分为多个按需加载的 chunk。然而，不当的拆分策略往往会导致同一模块被打包进多个 chunk 中，造成代码冗余和带宽浪费。Bundle-Buddy 正是为了解决这一问题而诞生的。

该工具的独特之处在于它完全基于 Source Map 工作，不依赖打包工具的内部统计信息（如 Webpack Stats），也不需要访问原始源代码文件。它读取打包产物的 .map 文件，解析其中的 sources 和 sourcesContent 字段，将压缩后的代码反向映射回原始源文件，然后交叉对比所有 chunk 的源文件列表——如果同一个源文件出现在多个 chunk 中，就会被标记为重复代码。这种打包工具无关（bundler-agnostic）的设计使其能够支持 Webpack、Rollup、esbuild、Parcel 等任意产出的 bundle。

该工具由 Sam Saccone（samccone）创建，他曾就职于 Google 和 Adobe，是 Webpack 核心维护者之一。项目于 2017 年启动，曾在 Webpack 官方博客上获得推广文章。但自 2019 年 10 月发布 npm v0.2.2 版本后，项目已超过 6 年未更新，处于事实上的不活跃维护状态。当前默认分支 bundle-explorer 是一个重构后的 Web App 版本，而原始 CLI 版本仍可通过 npm 安装。

基本信息

快速上手

安装

无需安装，直接使用 npx（推荐）：

npx bundle-buddy your-app/dist/*.map

全局安装：

npm install -g bundle-buddy
 
# 或使用 yarn
yarn global add bundle-buddy

项目本地安装（作为开发依赖）：

npm install --save-dev bundle-buddy
 
# 或使用 yarn
yarn add --dev bundle-buddy

Webpack 插件方式（自动集成到构建流程）：

npm install --save-dev bundle-buddy-webpack-plugin

基础配置

确保打包产物生成 Source Map

Bundle-Buddy 依赖 Source Map 文件工作，必须在打包时启用完整的 Source Map 生成：

Webpack 配置：

// webpack.config.js
module.exports = {
  // ...
  devtool: 'source-map', // 必须生成完整 source map
  // 注意：'hidden-source-map'、'eval-source-map' 等也可
  // 但不能为 false
}

Rollup 配置：

// rollup.config.js
export default {
  // ...
  output: {
    sourcemap: true, // 启用 source map
    sourcemapExcludeSources: false, // 必须保留源文件内容
  },
}

Vite 配置：

// vite.config.js
export default defineConfig({
  build: {
    sourcemap: true, // 生成 source map
  },
})

Webpack 插件配置

// webpack.config.js
const BundleBuddyWebpackPlugin = require('bundle-buddy-webpack-plugin')
 
module.exports = {
  // ...
  devtool: 'source-map',
  plugins: [
    new BundleBuddyWebpackPlugin({
      // 可选：自定义警告显示方式
      // 如果 devtool 未正确配置，插件会自动警告并设置为 'source-map'
    }),
  ],
}

注意事项

  • 必须使用支持 source map 的构建方式：Bundle-Buddy 的核心功能依赖 source map 中的 sources 字段和 sourcesContent 字段，如果 source map 被外部化到 CDN 或 inline 到 bundle 中，需要确保工具能正确访问
  • webpack-dev-server 不兼容：bundle-buddy-webpack-plugin 需要读取磁盘上的 .map 文件，与 webpack-dev-server 的虚拟文件系统不兼容（已知问题）

最小示例

以下是一个最简单的使用流程：

# 1. 使用 Webpack 构建项目（确保启用 source map）
npx webpack --mode production
 
# 2. 使用 Bundle-Buddy 分析产物中的重复代码
npx bundle-buddy dist/*.map

完整的最小可运行示例：

# 创建测试项目
mkdir bb-demo && cd bb-demo
 
# 初始化项目
npm init -y
npm install --save-dev webpack webpack-cli bundle-buddy
 
# 创建入口文件
echo 'console.log("hello")' > index.js
 
# 配置 webpack 生成 source map
cat > webpack.config.js << 'EOF'
module.exports = {
  mode: 'production',
  entry: './index.js',
  devtool: 'source-map',
  output: {
    filename: '[name].bundle.js',
    path: __dirname + '/dist',
  },
}
EOF
 
# 构建
npx webpack
 
# 运行 bundle-buddy 分析
npx bundle-buddy dist/*.map

核心概念与架构

核心概念

  1. Source Map 驱动分析：Bundle-Buddy 不读取原始源代码文件，而是完全依赖 Source Map 中嵌入的映射关系。一个 Source Map 文件本质上是一个 JSON 文件，其中 sources 字段记录了该 chunk 包含的所有原始源文件路径，sourcesContent 字段记录了每个源文件的完整内容。

  2. 重复定义：Bundle-Buddy 将"重复"定义为同一个原始源文件出现在多个输出 chunk 中。这与重复的 npm 包版本不同——即使同一个 npm 包只安装了一个版本，如果 code splitting 策略不当，该包的某些模块文件仍可能被打包到多个 chunk 中。

  3. Source Map 内容（sourcesContent）：Bundle-Buddy 的一个关键设计是它不需要访问原始源代码——通过读取 source map 中内嵌的 sourcesContent 字段，它可以确定每个文件在最终产物中的实际大小。

工作原理

Bundle-Buddy 的分析流程分为三个阶段：

┌─────────────────────────────────────────────────────────────────────────────┐
│                          Bundle-Buddy 工作流程                                │
├─────────────────────────────────────────────────────────────────────────────┤
│  Phase 1: 解析 Source Map                                                     │
│  ┌─────────────┐   ┌─────────────┐   ┌─────────────┐                          │
│  │ chunk-a.js  │   │ chunk-b.js  │   │ chunk-c.js  │  ← 输入 bundle 文件      │
│  │  .map       │   │  .map       │   │  .map       │  ← 对应 source map       │
│  └──────┬──────┘   └──────┬──────┘   └──────┬──────┘                          │
│         │                 │                 │                                  │
│         ▼                 ▼                 ▼                                  │
│  ┌──────────────────────────────────────────────────────┐                     │
│  │     解析每个 .map 文件，提取 sources + sourcesContent   │                     │
│  └──────────────────────────────────────────────────────┘                     │
│                                                                              │
│  Phase 2: 交叉对比                                                            │
│  ┌──────────────────────────────────────────────────────┐                     │
│  │     构建映射表：source_file → [chunk-a, chunk-b, ...]  │                     │
│  │     如果某个 source_file 对应的 chunk 列表 > 1，        │                     │
│  │     则该文件被标记为重复                                 │                     │
│  └──────────────────────────────────────────────────────┘                     │
│                                                                              │
│  Phase 3: 可视化输出                                                          │
│  ┌──────────────────────────────────────────────────────┐                     │
│  │     柱状图：高度 = 代码行数，颜色 = 重复 chunk 数量     │                     │
│  │     或 JSON 格式输出供下游处理                          │                     │
│  └──────────────────────────────────────────────────────┘                     │
└─────────────────────────────────────────────────────────────────────────────┘
  1. 解析阶段：使用 Mozilla 的 source-map 库（SourceMapConsumer）读取每个 .map 文件，提取所有源文件的路径和内容
  2. 对比阶段：构建一个反向索引（源文件路径 → 出现该文件的 chunk 列表），找出所有出现在 2 个及以上 chunk 中的文件
  3. 可视化阶段：以柱状图（bar chart）形式展示结果，柱的高度表示代码行数，颜色表示重复出现在多少个 chunk 中

架构特点

  • 打包工具无关：不依赖任何特定打包器的内部 API，只要有 source map 文件即可工作
  • 离线分析：不需要启动打包流程，对已有的构建产物进行后处理分析
  • 无源码依赖：不需要访问原始源代码文件，source map 中包含了所有必要信息
  • 支持多文件类型：不仅限于 JavaScript，任何有 source map 映射的文件（CSS、模板等）都可以分析

核心特性

  • Source Map 驱动的重复检测：基于 source map 文件分析重复代码，不需要访问原始源代码，也不需要打包工具的内部统计数据
  • 打包工具无关（Bundler-Agnostic）：支持任何能生成 source map 的打包工具——Webpack、Rollup、esbuild、Parcel、Browserify 等
  • Source Map 内容读取：通过读取 source map 中的 sourcesContent 字段，直接计算每个源文件在最终 bundle 中的实际大小
  • 多文件类型支持：不仅分析 JavaScript，还支持 CSS、模板等任何有 source map 映射的文件类型
  • CLI + Webpack 插件双模式：既可以通过命令行对已有产物进行离线分析，也可以通过 Webpack 插件集成到构建流程中
  • 可视化重复分布：以柱状图形式直观展示哪些文件在多少个 chunk 中重复出现，帮助快速定位最严重的冗余
  • Web App 版本（bundle-explorer）：重构后的 Web 应用版本，提供更丰富的交互式分析体验
  • Nuxt 模块集成：通过 nuxt-bundle-buddy 模块，可以在 Nuxt.js 项目中直接集成 Bundle-Buddy

生态图

生态系统概览

Bundle-Buddy 的生态相对轻量，主要围绕以下几个组件展开：

┌────────────────────────────────────────────────────────────────────────┐
│                    Bundle-Buddy 生态系统                                │
├────────────────────────────────────────────────────────────────────────┤
│                                                                        │
│  核心工具                                                              │
│  ├── bundle-buddy (npm)        — CLI 工具，核心分析引擎                 │
│  ├── bundle-buddy.com          — Web App 版本（bundle-explorer）        │
│  └── bundle-buddy-webpack-plugin — Webpack 构建集成插件                  │
│                                                                        │
│  社区集成                                                              │
│  ├── nuxt-bundle-buddy         — Nuxt.js 模块封装                      │
│  └── bundle-buddy-webpack-plugin-next — 更新版本的 webpack 插件          │
│                                                                        │
│  设计文档                                                              │
│  ├── Google Docs: 设计文档                                              │
│  └── Google Docs: TODO 列表                                            │
│                                                                        │
└────────────────────────────────────────────────────────────────────────┘

相关工具

工具定位与 Bundle-Buddy 的关系
webpack-bundle-analyzer可视化 bundle 内容侧重整体体积分布，不专门检测跨 chunk 重复
source-map-explorerSource Map 可视化分析单个 bundle 的体积构成
duplicate-package-checker-webpack-plugin重复包检测检测同一 npm 包的不同版本，与 Bundle-Buddy 互补
Rsdoctor一站式构建分析现代替代方案，支持重复依赖检测
inspectpack浪费字节分析检测 Webpack bundle 中的冗余和浪费
Bundlephobia包体积查询查询 npm 包的体积，不涉及跨 chunk 分析

替代品

鉴于 Bundle-Buddy 已长期未维护，以下是推荐的现代替代方案：

  1. Rsdoctor（最推荐）：一站式构建分析器，内置重复依赖检测，支持 Webpack 和 Rspack
  2. webpack-bundle-analyzer：最流行的 bundle 可视化工具，活跃维护
  3. source-map-explorer：轻量级 source map 分析工具
  4. Vite 内置 vite-bundle-analyzer：Vite 生态的原生方案
  5. rollup-plugin-visualizer：Rollup 生态的可视化分析工具

适用场景

  • Code Splitting 优化：当你使用 Webpack/Rollup 的 code splitting 功能将应用拆分为多个 chunk 时，Bundle-Buddy 能帮你发现哪些模块被不当地打包到了多个 chunk 中，从而指导你优化 splitChunks 配置

  • 多入口应用分析：对于有多个入口点（entry points）的应用（如 MPA 多页应用），不同入口可能共享大量依赖，Bundle-Buddy 可以识别这些共享模块，帮助你决定是使用 CommonsChunkPlugin（Webpack 4 以下）还是 optimization.splitChunks（Webpack 4+）来提取公共模块

  • 迁移期排查：在从 Webpack 3 迁移到 Webpack 4/5，或从 CommonsChunkPlugin 迁移到 splitChunks 的过程中，Bundle-Buddy 可以作为验证工具，确认迁移后的产物是否引入了新的代码重复

  • CI/CD 质量门禁：将 Bundle-Buddy 集成到 CI 流程中，在每次构建后检查是否存在超过阈值的重复代码，防止 code splitting 配置回退

  • 遗留项目审计：对于维护时间较长、经过多人修改的项目，Bundle-Buddy 可以帮助快速审计整个 bundle 中隐藏的重复代码，找出可以立即缩减的体积

  • 依赖管理策略验证：当你修改了 package.json 中的依赖版本或 alias 配置后，使用 Bundle-Buddy 验证这些变更是否真正消除了 bundle 中的重复代码

  • 性能预算监控：配合 Bundlephobia 等工具，Bundle-Buddy 可以作为性能预算工具链的一部分，专注于监控跨 chunk 的代码重复率

开发与工程化

开发流程

由于项目已长期不活跃，官方开发流程已无法参考。以下是基于历史代码结构的说明：

  1. 代码结构：项目主要由 TypeScript 编写，核心逻辑在 src/ 目录
  2. 构建系统：使用 TypeScript 编译器（tsc）进行编译
  3. 部署：Web App 版本通过 deploy.sh 脚本部署到 Google Cloud（需要 Google Cloud SDK）
  4. CI：历史版本使用 Travis CI 进行持续集成

CI/CD 集成

尽管项目不活跃，Bundle-Buddy 的 CLI 工具仍可以集成到现代 CI/CD 流程中：

GitHub Actions 示例：

name: Bundle Analysis
on: [push, pull_request]
 
jobs:
  analyze:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
 
      - name: Install dependencies
        run: npm ci
 
      - name: Build with source maps
        run: npx webpack --mode production
 
      - name: Run Bundle-Buddy
        run: npx bundle-buddy dist/*.map --json > bundle-buddy-report.json
 
      - name: Upload report
        uses: actions/upload-artifact@v4
        with:
          name: bundle-analysis
          path: bundle-buddy-report.json

自定义阈值检查脚本：

#!/bin/bash
# 检查重复文件数量是否超过阈值
REPORT=$(npx bundle-buddy dist/*.map --json 2>/dev/null)
DUPLICATE_COUNT=$(echo "$REPORT" | jq '.duplicates | length')
THRESHOLD=5
 
if [ "$DUPLICATE_COUNT" -gt "$THRESHOLD" ]; then
  echo "❌ 发现 $DUPLICATE_COUNT 个重复文件，超过阈值 $THRESHOLD"
  exit 1
else
  echo "✅ 重复文件数量 $DUPLICATE_COUNT，在阈值范围内"
fi

Webpack 插件集成

// webpack.config.js
const BundleBuddyWebpackPlugin = require('bundle-buddy-webpack-plugin')
 
module.exports = {
  mode: 'production',
  devtool: 'source-map',
  // ...
  plugins: [
    // 在构建完成后自动检查重复代码
    new BundleBuddyWebpackPlugin(),
  ],
}

性能与安全

性能特点

  • 分析速度：Bundle-Buddy 的分析速度主要受限于 source map 文件的大小和数量。对于中小型项目（几十个 chunk），分析通常在几秒内完成
  • 内存占用：由于需要将 source map 中的 sourcesContent 全部加载到内存中进行交叉对比，大型项目（数百个 chunk）可能会占用较多内存
  • 无侵入性：作为离线分析工具，不会影响应用的构建性能或运行时性能
  • Source Map 解析开销：Mozilla source-map 库的解析性能是瓶颈所在，对于非常大的 source map 文件（如包含数千个模块的 chunk），解析时间可能显著增加

安全注意事项

  • Source Map 泄露风险：Bundle-Buddy 依赖 source map 文件，而 source map 中包含了完整的原始源代码（sourcesContent）。在生产环境中部署 source map 文件存在安全风险——任何人都可以通过 source map 还原你的完整源代码。建议：
    • 在 CI/CD 中分析时使用临时生成的 source map，分析完成后立即删除
    • 生产环境使用 hidden-source-map（Webpack），生成 source map 但不添加 sourceMappingURL 注释
    • 将 source map 文件上传到私有错误监控服务（如 Sentry），而非公开部署
  • npm 包体积：bundle-buddy 的 npm 包解压后达 28.1 MB，可能包含历史构建产物。建议使用 npx 临时执行或作为 devDependency 安装
  • 依赖安全：项目已超过 6 年未更新，其依赖树可能存在已知漏洞。建议在使用前运行 npm audit 检查依赖安全性

技术对比

与同类工具的详细对比

特性bundle-buddyduplicate-package-checker-webpack-pluginwebpack-bundle-analyzersource-map-explorerRsdoctorinspectpack
检测粒度源文件级别npm 包级别模块级别文件级别包 + 模块级别模块级别
重复类型同一源文件出现在多个 chunk同一 npm 包的不同版本N/A（不做重复检测）N/A（体积分析）重复依赖 + 重复包浪费字节分析
Source Map 依赖✅ 必须❌ 不依赖❌ 使用 Stats JSON✅ 必须❌ 使用构建 API❌ 使用 Stats JSON
打包工具无关✅ 是❌ 仅 Webpack❌ 仅 Webpack✅ 是⚠️ Webpack/Rspack❌ 仅 Webpack
可视化✅ 柱状图❌ 仅终端警告✅ Treemap/Sunburst✅ Treemap✅ Web UI⚠️ 有限
CI/CD 集成⚠️ 需自行编写✅ 内置 fail 选项⚠️ 需自行编写⚠️ 需自行编写✅ 内置⚠️ 需自行编写
活跃维护（2026）❌ 停止（2019）❌ 停止（2019）✅ 活跃（2026.3）❌ 停滞（2022）✅ 活跃（2025+）❌ 停止（2020）
支持 Vite/Rollup✅ 是（有 source map 即可）❌ 否❌ 否✅ 是❌ 否❌ 否

关键差异说明

bundle-buddy vs duplicate-package-checker-webpack-plugin：

这是两种不同层面的重复检测：

  • Bundle-Buddy 检测的是同一源文件在多个 chunk 中的重复打包——即使你只有一个版本的 lodash，如果 code splitting 策略不当，lodash/map.js 可能同时出现在 chunk-a.js 和 chunk-b.js 中
  • duplicate-package-checker-webpack-plugin 检测的是同一 npm 包的不同版本共存——比如 [email protected] 和 [email protected] 同时被不同依赖引入

两者是互补关系，不是替代关系。理想情况下应该同时使用。

bundle-buddy vs webpack-bundle-analyzer：

  • Bundle-Buddy 专注于跨 chunk 的代码重复，回答"哪些文件在多个 chunk 中出现了"
  • webpack-bundle-analyzer 专注于整体体积分布，回答"我的 bundle 里都有什么，各占多大"
  • 两者可以同时使用：先用 webpack-bundle-analyzer 了解整体构成，再用 Bundle-Buddy 发现重复代码

bundle-buddy vs Rsdoctor（现代替代方案）：

Rsdoctor 是 2024 年推出的现代构建分析工具，功能覆盖 Bundle-Buddy 的所有场景并远超之：

  • 内置重复包检测规则
  • 支持 Webpack 和 Rspack
  • 提供 Web UI 可视化
  • 活跃维护，持续更新
  • 支持 Loader/Plugin/Resolver 级别的构建分析
  • 提供 MCP Server 集成（可与 AI 工具协作）

最佳实践

使用最佳实践

  1. 先分析，后优化：在修改 code splitting 配置之前，先用 Bundle-Buddy 建立基线——了解当前有多少文件存在重复、重复的规模有多大，然后有针对性地优化

  2. 结合 Webpack CommonsChunkPlugin / splitChunks 使用：Bundle-Buddy 的典型工作流是：

    构建 → 运行 Bundle-Buddy → 发现重复 → 调整 splitChunks 配置 → 重新构建 → 验证

  3. 关注高重复度的文件：优先处理那些出现在大量 chunk 中的文件——一个出现在 10 个 chunk 中的文件比只出现在 2 个 chunk 中的文件优先级更高

  4. 配合 duplicate-package-checker-webpack-plugin 使用：Bundle-Buddy 检测源文件级别的重复，duplicate-package-checker 检测 npm 包级别的重复，两者互补

  5. 在构建流程中生成 source map 用于分析，但不部署到生产环境：

    // webpack.config.js
module.exports = {
  // 使用 hidden-source-map：生成 source map 但不在产物中添加引用
  devtool: 'hidden-source-map',
}

  6. 定期运行审计：在 CI/CD 中集成 Bundle-Buddy 分析，建立重复代码的趋势跟踪，防止回归

常见陷阱

  • ⚠️ Source Map 未生成：最常见的错误是构建时未启用 source map 或使用了不包含 sourcesContent 的 source map 格式。确保使用 devtool: 'source-map' 或 devtool: 'hidden-source-map'
  • ⚠️ webpack-dev-server 不兼容：bundle-buddy-webpack-plugin 无法在 webpack-dev-server 中工作，因为它需要读取磁盘上的 .map 文件。请在生产构建模式下使用
  • ⚠️ 忽略 npm 包版本重复：Bundle-Buddy 只检测源文件级别的重复，不会告诉你 lodash@4 和 lodash@3 被同时打包了。需要配合 duplicate-package-checker-webpack-plugin 使用
  • ⚠️ 过度依赖可视化：Bundle-Buddy 的柱状图可视化虽然直观，但在大型项目中可能信息过载。建议先用 JSON 输出过滤，再针对性分析
  • ⚠️ 混淆"模块重复"与"包重复"：同一个 npm 包的不同模块文件可能分别出现在不同 chunk 中，这是正常的 code splitting 行为，不一定是问题。只有当一个模块文件本身在多个 chunk 中重复时才需要优化

替代方案推荐

鉴于 Bundle-Buddy 已长期不活跃，对于新项目推荐以下替代方案：

场景推荐工具理由
Webpack/Rspack 项目Rsdoctor功能全面，内置重复检测，活跃维护
需要可视化 bundle 构成webpack-bundle-analyzer最流行的 Treemap 可视化，2026 年仍在更新
任意打包器 + Source Map 分析source-map-explorer打包工具无关，轻量易用
Rollup/Vite 项目rollup-plugin-visualizer原生 Rollup 插件
CI/CD 集成BundleMon支持 GitHub Actions，自动追踪 bundle 大小趋势
依赖健康度检查depcheck / npm audit检查未使用的依赖和已知漏洞

技术局限与边界

已知限制

  1. 项目停止维护：最后一次 npm 发布是 2019 年 10 月（v0.2.2），已超过 6 年未更新。依赖树可能存在安全漏洞，且不支持新的打包工具特性（如 Webpack 5 Module Federation、Rspack 等）

  2. 仅检测源文件重复：Bundle-Buddy 检测的是"同一个源文件出现在多个 chunk 中"这种简单的重复模式。对于以下情况无法检测：

    • 功能相似但代码不同的重复逻辑（需要 AST 级别分析）
    • 不同版本的同一 npm 包（需要包管理器级别的检测）
    • 跨 bundle 的资源重复（如图片、字体等）

  3. Source Map 精度限制：分析结果的准确性完全依赖 source map 的质量。如果打包过程中使用了非标准的 source map 生成方式，或 source map 被工具链中的某些步骤修改/破坏，可能导致分析结果不准确

  4. Source Map 格式限制：只支持标准的 Source Map V3 格式（.map 文件）。不支持 inline source map、eval source map，也不支持 source map 被外部化到 CDN 的情况

  5. 大型项目性能瓶颈：对于包含数百个 chunk 的大型项目，解析所有 source map 并进行交叉对比可能导致内存占用过高和分析时间过长

  6. 无增量分析能力：每次分析都需要重新解析所有 source map 文件，不支持增量分析或缓存，在 CI/CD 中每次全量分析可能耗时较长

  7. 不支持 ES Module 级别的分析：Bundle-Buddy 的重复检测粒度是"源文件"级别，而不是"ES Module export"级别。如果一个源文件导出了 10 个函数，只有 1 个被使用，Bundle-Buddy 仍会将整个源文件标记为重复

不适用场景

  • 纯 ESM 分析：如果需要分析 ESM 的 tree-shaking 效果或 import/export 级别的依赖关系，Bundle-Buddy 无法胜任
  • 运行时性能分析：Bundle-Buddy 是静态分析工具，无法告诉你重复代码在运行时是否真的被执行
  • 微前端架构：对于 Module Federation 等微前端架构，不同应用间的共享模块检测需要专门的工具支持
  • 非 JavaScript 产物：虽然理论上支持任何有 source map 的文件，但 Bundle-Buddy 的可视化主要面向 JavaScript 生态

权衡取舍

优势代价
打包工具无关，适用范围广无法利用打包器内部信息做更深入的分析
不需要访问原始源代码依赖 source map 的质量和完整性
检测源文件级别的精确重复无法检测语义级别的代码重复
CLI 使用简单，零配置缺乏高级配置选项（如阈值、白名单）
无侵入性，离线分析无法实时监控构建变化

学习资源

官方文档

教程与文章

社区资源

2026 年现状

当前状态：不活跃维护 ⚠️

指标状态
最后 npm 发布2019-10-04（超过 6 年前）
GitHub 活跃提交已停止多年
最后 Issue 活动2023 年
维护者状态Sam Saccone 已转向其他项目
依赖安全性可能存在已知漏洞，未更新
兼容现代打包工具⚠️ 未针对 Webpack 5+、Vite、Rspack 等新工具适配

替代方案推荐

对于 2026 年的新项目，不推荐使用 Bundle-Buddy 作为主要分析工具。推荐以下替代方案：

  1. Rsdoctor（首选）

    • 地址：https://rsdoctor.rs/
    • 优势：一站式构建分析、内置重复依赖检测规则、Web UI、支持 Webpack 5 和 Rspack、活跃维护
    • 适合：Webpack/Rspack 项目的全方位构建分析

  2. webpack-bundle-analyzer

  3. source-map-explorer

  4. BundleMon

  5. Vite/Rollup 生态

    • rollup-plugin-visualizer：Rollup 原生插件
    • vite-plugin-inspect：Vite 开发调试工具
    • 适合：Vite/Rollup 项目

结论

Bundle-Buddy 在 2017-2019 年间是一个创新性的工具，首次系统性地利用 Source Map 检测跨 chunk 的代码重复问题。它的核心理念——通过 Source Map 理解 bundle 中每一字节的来源——仍然深刻影响了后续的 bundle 分析工具。然而，该项目已长期停止维护，其功能已被 Rsdoctor 等现代工具全面覆盖。建议将 Bundle-Buddy 视为一个了解 bundle 分析历史的学习资源，而非生产工具。对于实际的重复代码检测需求，应优先使用 Rsdoctor、webpack-bundle-analyzer 等活跃维护的现代工具。