从零构建 JavaScript 模块打包器：理解 Vite/Rollup 底层原理

每天有数百万开发者敲下 vite build 或 rollup -c，但很少有人真正理解这行命令背后发生了什么。根据 2026 年 State of Frontend 工具调查，超过 89% 的前端项目使用模块打包器，但只有不到 12% 的开发者能说清楚打包器内部的模块解析、依赖图构建和代码生成流程。如果你曾经好奇过「为什么 Tree Shaking 能删除未使用的代码」「为什么 Code Splitting 能按需加载」，那么这篇文章就是你的答案——我们将从零实现一个支持 ES Modules、依赖图构建和 Tree Shaking 的迷你打包器（Mini Bundler）。

📌 记住： 本文的目标不是造一个生产级打包器，而是通过亲手实现核心机制，让你真正理解 Vite、Rollup、esbuild 背后的设计思路。理解原理后，你在使用这些工具时的调试能力和配置能力会有质的飞跃。

📦 一、模块打包器的核心架构

1.1 打包器到底在做什么？

模块打包器的本质是一个构建流水线，它将多个独立的模块文件转换成浏览器（或 Node.js）可执行的产物。这个过程可以拆解为四个核心阶段：

这四个阶段中，解析和图构建决定了打包器能处理什么样的模块系统（CommonJS、ESM、AMD），包装决定了运行时的模块加载机制，优化决定了最终产物的体积和性能。

1.2 ESM 与 CJS 的本质区别

理解打包器之前，必须先理解两种模块系统的根本差异：

• ✅ ES Modules（ESM）：静态结构，import/export 在编译时确定，支持 Tree Shaking
• ❌ CommonJS（CJS）：动态结构，require() 可以出现在任何位置，难以静态分析

// ESM — 静态导入，打包器在编译时就能知道依赖关系
import { calculate } from './math.js'
export const result = calculate(42)

// CJS — 动态导入，打包器必须执行代码才能知道实际依赖
const module = require(someVariable ? './math-a.js' : './math-b.js')

⚠️ 警告： CJS 的 require() 可以接受变量，这意味着打包器在不执行代码的情况下无法确定完整的依赖关系。这就是为什么 ESM 天然更适合 Tree Shaking。

现代打包器（Rollup、Vite、esbuild）都优先处理 ESM，本文的实现也以 ESM 为核心。

🔧 二、从零实现 Mini Bundler

2.1 第一步：模块解析器（Module Resolver）

模块解析器的任务是：给定一个文件路径，读取其内容，并提取所有的 import 和 export 语句。

// module-resolver.js — 模块解析器：读取文件并提取 import/export
import { readFileSync } from 'fs'
import { dirname, resolve, extname } from 'path'
import { parse } from 'acorn'

/**
 * 解析单个模块，返回模块元数据
 * @param {string} filePath - 模块的绝对路径
 * @returns {{ id, code, dependencies, exports }}
 */
export function resolveModule(filePath) {
  const code = readFileSync(filePath, 'utf-8')
  const ast = parse(code, {
    sourceType: 'module',
    ecmaVersion: 2024
  })

  const dependencies = []  // 本模块依赖的其他模块路径
  const exports = []       // 本模块导出的标识符

  // 遍历 AST 顶层节点，提取 import 和 export
  for (const node of ast.body) {
    // 处理 import 语句：import xxx from './xxx.js'
    if (node.type === 'ImportDeclaration') {
      const depPath = resolve(dirname(filePath), node.source.value)
      dependencies.push(depPath)
    }

    // 处具名导出：export { a, b } 或 export const x = 1
    if (node.type === 'ExportNamedDeclaration') {
      if (node.declaration) {
        // export const foo = 1 → 导出名 'foo'
        if (node.declaration.declarations) {
          node.declaration.declarations.forEach(decl => {
            exports.push(decl.id.name)
          })
        }
        // export function bar() {} → 导出名 'bar'
        if (node.declaration.id) {
          exports.push(node.declaration.id.name)
        }
      }
      // export { a, b }
      if (node.specifiers) {
        node.specifiers.forEach(spec => {
          exports.push(spec.local.name)
        })
      }
    }

    // 处理默认导出：export default xxx
    if (node.type === 'ExportDefaultDeclaration') {
      exports.push('default')
    }
  }

  return { id: filePath, code, dependencies, exports }
}

💡 提示： 我们使用 acorn 作为 AST 解析器，它是 Rollup 内部使用的同一个解析器。acorn 轻量、快速、符合 ECMAScript 规范。在生产级打包器中，esbuild 用 Go 写的解析器，速度比 acorn 快 10-100 倍。

2.2 第二步：依赖图构建器（Graph Builder）

有了模块解析器，下一步是递归遍历所有依赖，构建完整的依赖图。这是一个典型的深度优先遍历：

// graph-builder.js — 依赖图构建器：递归构建模块依赖图
import { resolveModule } from './module-resolver.js'

/**
 * 从入口文件出发，递归构建完整的模块依赖图
 * @param {string} entryPath - 入口文件的绝对路径
 * @returns {Map<string, object>} 模块 ID → 模块元数据
 */
export function buildGraph(entryPath) {
  const graph = new Map()       // 存储所有已分析的模块
  const queue = [entryPath]     // 待分析队列

  while (queue.length > 0) {
    const currentPath = queue.shift()

    // 跳过已分析过的模块（处理循环依赖）
    if (graph.has(currentPath)) continue

    // 解析当前模块
    const module = resolveModule(currentPath)
    graph.set(currentPath, module)

    // 将未分析的依赖加入队列
    for (const dep of module.dependencies) {
      if (!graph.has(dep)) {
        queue.push(dep)
      }
    }
  }

  return graph
}

这段代码虽然简短，但解决了两个关键问题：

• ✅ 循环依赖处理：通过 graph.has() 检查避免无限递归
• ✅ 广度优先遍历：保证依赖关系按层级展开，便于后续的拓扑排序

⚠️ 警告： 生产级打包器（如 Rollup）会对依赖图进行拓扑排序，确保模块的执行顺序正确——被依赖的模块先执行。我们的简化版本通过 BFS 的自然顺序近似实现了这一点，但在存在循环依赖时可能需要额外处理。

2.3 第三步：代码生成器（Code Generator）

这是打包器最核心的部分——将依赖图转换成可执行的代码。我们采用类似 Rollup 的「包装函数」模式：每个模块被包装成一个函数，通过一个模块注册表按需执行：

// code-generator.js — 代码生成器：将依赖图转换为可执行代码
import { buildGraph } from './graph-builder.js'
import { transform } from './transformer.js'

/**
 * 从入口文件生成打包后的代码
 * @param {string} entryPath - 入口文件绝对路径
 * @returns {string} 打包后的可执行代码
 */
export function generate(entryPath) {
  const graph = buildGraph(entryPath)

  // 为每个模块生成一个包装函数
  const modules = []
  for (const [id, module] of graph) {
    // 转换 import/export 为运行时调用
    const transformedCode = transform(module.code, module.exports)
    // 使用相对路径作为模块 ID，更可读
    const moduleId = './' + id.split('/').pop()
    modules.push(`  "${moduleId}": function(module, exports, require) {\n${transformedCode}\n  }`)
  }

  // 生成最终的打包代码
  return `
// === Mini Bundler Output ===
(function(modules) {
  var installed = {} // 模块缓存，避免重复执行

  // 模块加载函数
  function __require(moduleId) {
    if (installed[moduleId]) return installed[moduleId].exports

    var module = { exports: {} }
    installed[moduleId] = module

    // 执行模块函数
    modules[moduleId](module, module.exports, __require)

    return module.exports
  }

  // 加载入口模块
  return __require("./${entryPath.split('/').pop()}");
})({
${modules.join(',\n')}
});
`
}

这段代码实现了一个经典的模块运行时（Module Runtime），它的核心机制是：

1. 模块注册表：所有模块被注册到一个对象中，以路径为键
2. 懒执行：模块函数在首次被 require 时才执行
3. 缓存机制：installed 对象确保每个模块只执行一次
4. 闭包隔离：每个模块有自己的 module、exports 作用域

⚠️ 警告： 真实的打包器还需要处理动态 import()、CSS 导入、JSON 模块等特殊情况。我们的简化版本专注于核心逻辑，帮助你理解「为什么这样设计」。

🚀 三、进阶特性：Tree Shaking 与代码分割

3.1 Tree Shaking 的原理与实现

Tree Shaking 是打包器最令人称道的优化能力。它的核心思想很简单：如果一个导出从未被任何模块使用，那么它的代码应该被删除。

但「简单」的背后有一系列严格的条件：

我们实现一个简化版的 Tree Shaking 算法：

// tree-shaker.js — Tree Shaking：标记并删除未使用的导出
import { buildGraph } from './graph-builder.js'

/**
 * 从依赖图中找出所有被使用的导出，标记未使用的导出
 * @param {Map} graph - 模块依赖图
 * @param {string} entryPath - 入口文件路径
 * @returns {Map<string, Set<string>>} 每个模块中被使用的导出名
 */
export function treeShake(graph, entryPath) {
  const usedExports = new Map() // moduleId → Set<exportName>

  // 初始化：每个模块的 usedExports 为空集合
  for (const [id] of graph) {
    usedExports.set(id, new Set())
  }

  // 从入口模块开始，标记入口使用的所有导出
  markUsed(graph, entryPath, usedExports, new Set())

  return usedExports
}

/**
 * 递归标记：分析一个模块中哪些导出被使用，并追踪到被依赖的模块
 */
function markUsed(graph, moduleId, usedExports, visited) {
  if (visited.has(moduleId)) return // 避免循环
  visited.add(moduleId)

  const module = graph.get(moduleId)
  if (!module) return

  // 分析当前模块的代码，找出使用了依赖的哪些导出
  for (const depPath of module.dependencies) {
    const depModule = graph.get(depPath)
    if (!depModule) continue

    // 简化逻辑：假设入口模块使用了依赖的所有导出
    // 生产级打包器会做精确的变量追踪
    for (const exp of depModule.exports) {
      usedExports.get(depPath).add(exp)
    }

    // 递归处理被使用的依赖
    markUsed(graph, depPath, usedExports, visited)
  }
}

💡 提示： Rollup 的 Tree Shaking 比我们的实现精确得多——它会追踪每个变量的使用链路，精确到单个函数级别的死代码删除。我们的简化版展示了核心思想：从入口出发，标记可达的导出，删除不可达的代码。

在代码生成阶段，我们可以利用 usedExports 来过滤输出：

// 在 code-generator.js 中使用 Tree Shaking 结果
function generateShakenCode(module, usedExports) {
  const used = usedExports.get(module.id)
  // 如果没有任何导出被使用，整个模块可以跳过
  if (used.size === 0) return '// [tree-shaken] Module removed'
  // 否则只保留被使用的导出
  // （实际实现需要对 AST 做更精确的裁剪）
  return module.code
}

3.2 代码分割（Code Splitting）基础

代码分割是打包器的另一个核心能力。它的本质是：当一个模块通过动态 import() 导入时，将其打包成一个独立的 chunk。

// 动态导入 — 这是一个「分割点」（split point）
const module = await import('./heavy-module.js')

实现代码分割的核心思路：

// code-splitter.js — 代码分割：识别动态导入，生成独立 chunk
import { parse } from 'acorn'

/**
 * 检测代码中的动态 import() 调用
 * @param {string} code - 模块代码
 * @param {string} currentDir - 当前模块所在目录
 * @returns {string[]} 动态导入的模块路径
 */
export function findDynamicImports(code, currentDir) {
  const ast = parse(code, { sourceType: 'module', ecmaVersion: 2024 })
  const dynamicDeps = []

  // 递归遍历 AST 查找 ImportExpression 节点
  function walk(node) {
    if (!node || typeof node !== 'object') return
    // import('xxx') 对应 AST 中的 ImportExpression 类型
    if (node.type === 'ImportExpression' && node.source.type === 'Literal') {
      dynamicDeps.push(resolve(currentDir, node.source.value))
    }
    for (const key in node) {
      if (Array.isArray(node[key])) {
        node[key].forEach(walk)
      } else if (node[key] && typeof node[key] === 'object') {
        walk(node[key])
      }
    }
  }

  walk(ast)
  return dynamicDeps
}

代码分割后，打包器会生成多个 chunk 文件，运行时通过异步加载（通常是创建 <script> 标签或 fetch）来按需获取这些 chunk。

⚠️ 警告： 过度代码分割会导致大量小文件的 HTTP 请求，反而降低性能。经验法则是：每个 chunk 的 gzip 体积至少应大于 20KB，否则合并打包更优。

📊 四、与主流打包器的架构对比

理解了我们的 Mini Bundler 之后，来看它与主流打包器的架构差异：

从这个对比中可以看出一个关键趋势：esbuild 用 Go 重写后，构建速度比 JavaScript 实现快 10-100 倍。这直接催生了 Vite 的架构——开发时用 esbuild 做依赖预构建，生产时用 Rollup 做完整构建。TypeScript 6 的 tsgo 也是同一思路的延伸。

✅ 五、最佳实践与总结

5.1 打包器选型建议

根据项目规模和场景，选择合适的打包器：

• ✅ 小型项目 / 库开发：Rollup — 输出最干净，Tree Shaking 最精确
• ✅ 中型项目 / 快速迭代：Vite — 开发体验最佳，HMR 极快
• ✅ 大型项目 / Monorepo：Rspack / Turbopack — Rust/Go 重写，构建速度碾压级
• ❌ 不要在新项目中使用 Webpack — 除非有大量遗留插件必须兼容

5.2 理解打包器后的实践价值

当你理解了打包器的工作原理，很多之前「背配置」的行为就变成了「理解配置」：

1. 为什么 sideEffects: false 能减小体积？ → 因为打包器会假设你的模块没有副作用，可以安全删除未使用的导出
2. 为什么动态 import() 能做代码分割？ → 因为打包器将它识别为分割点，生成独立的 chunk
3. 为什么 Vite 开发模式这么快？ → 因为它不需要打包，直接通过浏览器原生 ESM 加载模块

⚡ 关键结论： 打包器不是一个黑盒——它是模块解析、依赖图构建、代码包装和死代码删除这四个步骤的组合。理解这四步，你就理解了整个前端构建工具链的底层逻辑。

5.3 延伸阅读

• 📖 Vite 原理深度解析 — Evan You 对 Vite 架构的官方解释
• 📖 Rollup 设计哲学 — 为什么 Rollup 选择 ESM-first
• 📖 esbuild 为什么这么快 — 并行化、零拷贝、共享 AST 的设计

在 jsjson.com 上，我们提供了 JSON 格式化工具、Base64 编解码 等在线工具，帮助开发者在不安装任何环境的情况下快速处理数据。所有处理都在浏览器本地完成，不上传服务器——这和现代打包器「优先本地处理」的理念一脉相承。