Webpack 深度解析

为什么还要学 Webpack

尽管 Vite 已成为新项目的主流选择，但 Webpack 仍是存量最大的构建工具——大量企业级项目、微前端架构、复杂定制构建仍依赖 Webpack。面试中 Webpack 的考察频率依然很高，且其设计思想（dependency graph、code splitting、plugin 架构）对理解所有 bundler 都有帮助。

核心概念

Entry

入口点定义了 Webpack 开始构建依赖图的起始模块。

// 单入口
module.exports = {
  entry: './src/index.js',
};

// 多入口
module.exports = {
  entry: {
    app: './src/app.js',
    admin: './src/admin.js',
  },
};

多入口会生成多个独立的 dependency graph，适用于多页应用（MPA）或需要拆分入口的场景。

Output

控制 bundle 的输出位置和命名。

module.exports = {
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: '[name].[contenthash:8].js',  // 用 contenthash 做长效缓存
    chunkFilename: '[name].[contenthash:8].chunk.js',
    clean: true,  // Webpack 5: 每次构建前清理 dist
  },
};

contenthash vs chunkhash vs hash：

Loader

Loader 是 Webpack 处理非 JS 文件的机制。Webpack 原生只理解 JavaScript 和 JSON，其他类型（TypeScript、CSS、图片等）需要通过 Loader 转换。

module.exports = {
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        use: 'ts-loader',
        exclude: /node_modules/,
      },
      {
        test: /\.css$/,
        use: ['style-loader', 'css-loader', 'postcss-loader'],
        // Loader 从右向左（从下往上）执行
        // postcss-loader → css-loader → style-loader
      },
    ],
  },
};

Loader 的本质：接收源文件内容（字符串或 Buffer），返回转换后的 JavaScript 代码。一个简单的 Loader：

// my-loader.js
module.exports = function(source) {
  // this.getOptions() 获取配置
  // this.async() 支持异步
  return source.replace(/console\.log\(.*?\);?/g, '');
};

Plugin

Plugin 在 Webpack 构建生命周期的各个钩子（hooks）上执行自定义逻辑，能力范围比 Loader 大得多。

// Plugin 的基本结构
class MyPlugin {
  apply(compiler) {
    // compiler: 整个构建过程的顶层对象
    compiler.hooks.emit.tapAsync('MyPlugin', (compilation, callback) => {
      // compilation: 单次构建的上下文，包含所有 modules/chunks/assets
      console.log('Assets about to be emitted');
      callback();
    });
  }
}

Loader vs Plugin 的区别（面试常考）：

Module 与 Module Resolution

Webpack 中的 Module 是一切可被引用的单元——JS 文件、CSS、图片、JSON、甚至 WASM。

Module Resolution 规则：

1. 绝对路径：直接使用
2. 相对路径：基于当前文件目录解析
3. 模块路径：在 resolve.modules（默认 node_modules）中查找
4. 别名：通过 resolve.alias 映射

module.exports = {
  resolve: {
    extensions: ['.ts', '.tsx', '.js', '.jsx'],
    alias: {
      '@': path.resolve(__dirname, 'src'),
    },
  },
};

构建流程：从源码到 Bundle

完整流程

Entry → Module Resolution → Loader Transform → Dependency Graph
  → Chunk Optimization → Code Generation → Asset Emission

详细步骤：

1. 初始化阶段

   • 读取配置文件，合并默认配置
   • 创建 Compiler 实例，注册所有 Plugin

2. 编译阶段（Make）

   • 从 Entry 出发，调用对应 Loader 转换模块内容
   • 解析 AST，分析 import/require 语句，递归处理依赖
   • 构建完整的 Dependency Graph（有向依赖图）

3. 优化阶段（Seal）

   • 将 Dependency Graph 切分为 Chunks
   • 执行 Tree Shaking（标记未使用的 exports）
   • 执行 Scope Hoisting（模块合并）
   • 应用 splitChunks 配置拆分公共代码

4. 输出阶段（Emit）

   • 将 Chunks 转换为最终的 Bundle 文件
   • 生成 runtime 代码（模块加载器）
   • 写入文件系统

Chunk 类型

Compiler vs Compilation

Module Federation

Module Federation 是 Webpack 5 引入的重要特性，允许多个独立构建在运行时共享模块，是微前端架构的核心技术方案之一。

核心角色

一个应用可以同时是 Host 和 Remote（双向联邦）。

工作原理

┌─────────────┐     加载 remoteEntry.js     ┌─────────────┐
│    Host      │  ─────────────────────────► │   Remote     │
│  (主应用)    │                              │  (微应用)    │
│              │  ◄───────────────────────── │              │
│  consumes    │    返回 exposed module       │  exposes     │
│  ./Button    │                              │  ./Button    │
└──────┬──────┘                              └──────┬──────┘
       │            Shared Scope                     │
       └─────────── (React, React-DOM) ─────────────┘

1. Remote 构建时生成 remoteEntry.js——一个"清单文件"，描述了暴露的模块和共享依赖
2. Host 在运行时加载 Remote 的 remoteEntry.js
3. 通过 Shared Scope 协商共享依赖的版本（基于 semver 规则）
4. 异步加载 Remote 暴露的具体模块

配置示例

// Remote 应用 — webpack.config.js
const { ModuleFederationPlugin } = require('webpack').container;

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'remoteApp',
      filename: 'remoteEntry.js',
      exposes: {
        './Button': './src/components/Button',
        './utils': './src/shared/utils',
      },
      shared: {
        react: { singleton: true, requiredVersion: '^18.0.0' },
        'react-dom': { singleton: true, requiredVersion: '^18.0.0' },
      },
    }),
  ],
};

// Host 应用 — webpack.config.js
module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'hostApp',
      remotes: {
        remoteApp: 'remoteApp@https://cdn.example.com/remoteEntry.js',
      },
      shared: {
        react: { singleton: true, requiredVersion: '^18.0.0' },
        'react-dom': { singleton: true, requiredVersion: '^18.0.0' },
      },
    }),
  ],
};

Shared 依赖协商机制

Dynamic Remotes

运行时动态决定 Remote 的 URL，适用于配置驱动的微前端架构：

// 运行时动态加载 remote
const loadRemote = async (url, scope, module) => {
  await __webpack_init_sharing__('default');
  const container = await loadScript(url);
  await container.init(__webpack_share_scopes__.default);
  const factory = await container.get(module);
  return factory();
};

Module Federation 2.0

随着 Rspack 的发展，Module Federation 2.0 带来了：

• Runtime Plugin 系统：更灵活的运行时控制
• Manifest 协议：替代 remoteEntry.js 的更标准化的模块发现机制
• TypeScript 类型提示：跨应用的类型安全

性能优化

Code Splitting — splitChunks

optimization.splitChunks 是 Webpack 内置的代码拆分策略，替代了早期的 CommonsChunkPlugin。

module.exports = {
  optimization: {
    splitChunks: {
      chunks: 'all',          // 对同步和异步 chunk 都拆分
      minSize: 20000,          // 最小 20KB 才拆分
      minChunks: 1,            // 至少被引用 1 次
      maxAsyncRequests: 30,    // 异步加载时最大并行请求数
      maxInitialRequests: 30,  // 入口点最大并行请求数
      cacheGroups: {
        vendors: {
          test: /[\\/]node_modules[\\/]/,
          name: 'vendors',
          priority: -10,
          reuseExistingChunk: true,
        },
        common: {
          minChunks: 2,
          priority: -20,
          reuseExistingChunk: true,
        },
      },
    },
    // 将 runtime 代码单独提取
    runtimeChunk: 'single',
  },
};

splitChunks 策略的核心考量：

• 太大的 chunk：首次加载慢，缓存失效影响大
• 太多的 chunk：HTTP 请求数增多（HTTP/2 下影响较小）
• 平衡点：按更新频率拆分——vendor（极少变）、common（较少变）、业务代码（频繁变）

持久化缓存（Webpack 5）

Webpack 5 引入了文件系统级别的持久化缓存，大幅提升二次构建速度：

module.exports = {
  cache: {
    type: 'filesystem',
    buildDependencies: {
      config: [__filename],  // 配置文件变化时使缓存失效
    },
    version: '1.0',           // 手动控制缓存版本
  },
};

效果：首次构建速度不变，后续构建通常能快 60%~80%。

DLL Plugin（了解级）

DLLPlugin 预先编译不常变化的第三方库，避免每次构建都重新处理。

// webpack.dll.config.js — 单独构建 DLL
module.exports = {
  entry: { vendor: ['react', 'react-dom', 'lodash'] },
  output: { filename: '[name].dll.js', library: '[name]_dll' },
  plugins: [
    new webpack.DllPlugin({
      name: '[name]_dll',
      path: path.join(__dirname, 'dll', '[name]-manifest.json'),
    }),
  ],
};

// webpack.config.js — 主构建引用 DLL
module.exports = {
  plugins: [
    new webpack.DllReferencePlugin({
      manifest: require('./dll/vendor-manifest.json'),
    }),
  ],
};

注意：在 Webpack 5 的 persistent cache 出现后，DLL 的必要性大幅降低。新项目推荐直接用 cache: { type: 'filesystem' }。

Tree Shaking

Tree Shaking 依赖 ES Modules 的静态结构，在编译时标记未被使用的 export，在压缩阶段删除。

使 Tree Shaking 生效的条件：

1. 使用 ES Modules 语法（import/export），不能是 require
2. package.json 中设置 "sideEffects": false（或列出有副作用的文件）
3. 使用支持 dead code elimination 的压缩器（Terser）
4. mode: 'production'

// package.json
{
  "sideEffects": [
    "*.css",
    "./src/polyfills.js"
  ]
}

Scope Hoisting（Module Concatenation）

将多个小模块合并到一个函数作用域中，减少函数声明和闭包开销：

module.exports = {
  optimization: {
    concatenateModules: true,  // production 模式默认开启
  },
};

其他优化手段

Webpack vs Vite 架构对比

开发模式

生产模式

为什么 Vite 在开发环境更快

Webpack 开发模式:
  源文件 → 解析全部依赖 → Loader 转换 → 构建 bundle → 服务给浏览器
  (慢在：全量处理)

Vite 开发模式:
  node_modules → esbuild 预构建 (一次性，极快)
  源文件 → 浏览器请求时按需转换 → 原生 ESM 直接加载
  (快在：按需 + esbuild)

何时仍需要 Webpack

何时选择 Vite

Rspack — Webpack 的 Rust 替代

Rspack 是字节跳动开源的 Webpack 兼容打包器，用 Rust 重写了核心编译流程：

• API 兼容：大部分 Webpack 配置和 loader 可直接使用
• 性能：构建速度提升 5~10 倍
• 定位：面向 Webpack 存量项目的渐进式升级方案

面试中如何组织 Webpack 相关回答

被问到"介绍一下 Webpack 的构建流程"

Webpack 的构建流程可以分为三个阶段。首先是初始化阶段，读取配置并创建 Compiler 实例，注册所有 Plugin。然后是编译阶段（Make），从 Entry 出发递归解析每个模块的依赖关系，通过 Loader 转换非 JS 文件，最终构建出完整的 Dependency Graph。最后是优化和输出阶段（Seal → Emit），将依赖图切分为 Chunks，执行 Tree Shaking 和 Scope Hoisting，再通过 splitChunks 拆分公共代码，最终将每个 Chunk 转换为 Bundle 文件输出。

被问到"Webpack 和 Vite 有什么区别"

最本质的区别在于开发模式的架构。Webpack 是 bundle-first——需要先将所有源文件打包成 bundle 再启动 dev server，启动时间随项目规模线性增长。Vite 利用浏览器原生 ESM，开发时不打包源文件，只用 esbuild 预构建 node_modules 依赖，浏览器请求时才按需转换——所以冷启动几乎是恒定时间。

但在生产构建上两者都是打包的：Webpack 用自身，Vite 用 Rollup。Webpack 的优势在于极其成熟的插件生态和 Module Federation 的原生支持；Vite 的优势在于更好的开发体验和更简洁的配置。新项目我会优先选 Vite，存量 Webpack 项目如果迁移成本高，可以考虑 Rspack 作为渐进升级方案。

延展阅读

• Webpack Concepts
• Webpack: Code Splitting
• Webpack: Tree Shaking