webpack · 识汐 Wikitide

一、Webpack 是什么？

Webpack 是一个现代 JavaScript 应用程序的静态模块打包工具（Static Module Bundler）。它将项目中所有的模块（JS、CSS、图片、字体等）视为依赖图（Dependency Graph）的节点，从入口文件出发，递归构建依赖关系，最终打包成一个或多个 bundle 文件。

Entry（入口）
    ↓
Dependency Graph（依赖图谱构建）
    ↓
Loaders（转换各类资源）
    ↓
Plugins（执行更广泛的构建任务）
    ↓
Output（输出 bundle）

💡 面试要点： 能清楚地描述 Webpack 的整体工作流程，是面试加分项。

二、核心概念（Core Concepts）

1. Entry（入口）

Entry 是 Webpack 构建依赖图的起始点，可配置单入口或多入口。

// webpack.config.js

// 单入口（SPA 常用）
module.exports = {
  entry: './src/index.js',
}

// 多入口（MPA 多页应用）
module.exports = {
  entry: {
    home: './src/home.js',   // 主页入口
    about: './src/about.js', // 关于页入口
  },
}

2. Output（输出）

Output 告诉 Webpack 在哪里输出打包文件以及如何命名。

const path = require('path')

module.exports = {
  output: {
    path: path.resolve(__dirname, 'dist'),  // 输出目录（绝对路径）
    filename: '[name].[contenthash].js',    // 使用 contenthash 做缓存控制
    clean: true,                            // 构建前清空 dist 目录
  },
}

占位符	说明
`[name]`	chunk 的名称（entry 的 key）
`[hash]`	每次构建生成的唯一 hash
`[chunkhash]`	基于 chunk 内容的 hash
`[contenthash]`	基于文件内容的 hash，最推荐用于缓存

3. Loader（加载器）

Loader 让 Webpack 能够处理非 JS 文件（CSS、图片、TypeScript 等）。Loader 本质上是一个函数，接收源文件内容，返回转换后的结果。

⚠️ 注意： Loader 的执行顺序是从右到左、从下到上的！

module.exports = {
  module: {
    rules: [
      {
        test: /\.css$/,
        // 执行顺序：css-loader → style-loader（右→左）
        use: ['style-loader', 'css-loader'],
      },
      {
        test: /\.tsx?$/,
        use: 'ts-loader',       // TypeScript 转换
        exclude: /node_modules/,
      },
      {
        test: /\.(png|jpg|gif|svg)$/,
        type: 'asset/resource', // Webpack 5 内置资源模块
      },
    ],
  },
}

常见 Loader 汇总：

Loader	用途
`babel-loader`	将 ES6+ 转换为 ES5
`ts-loader` / `esbuild-loader`	处理 TypeScript
`css-loader`	解析 CSS 中的 `@import` 和 `url()`
`style-loader`	将 CSS 注入到 DOM 的 `<style>` 标签
`sass-loader`	编译 SCSS/SASS
`postcss-loader`	自动添加浏览器前缀等后处理
`file-loader` / `url-loader`	处理文件资源（Webpack 5 已内置）
`vue-loader`	处理 `.vue` 单文件组件

4. Plugin（插件）

Plugin 用于执行比 Loader 更广泛的任务，如打包优化、资源管理、注入环境变量等。Plugin 通过钩子（Hook）机制介入 Webpack 的整个生命周期。

const HtmlWebpackPlugin = require('html-webpack-plugin')
const MiniCssExtractPlugin = require('mini-css-extract-plugin')
const { DefinePlugin } = require('webpack')

module.exports = {
  plugins: [
    // 自动生成 HTML 并注入 bundle
    new HtmlWebpackPlugin({ template: './public/index.html' }),

    // 将 CSS 提取为单独文件（生产环境）
    new MiniCssExtractPlugin({ filename: '[name].[contenthash].css' }),

    // 注入全局环境变量
    new DefinePlugin({
      'process.env.NODE_ENV': JSON.stringify('production'),
    }),
  ],
}

常见 Plugin 汇总：

Plugin	用途
`HtmlWebpackPlugin`	自动生成 HTML 并注入 script 标签
`MiniCssExtractPlugin`	提取 CSS 为独立文件
`DefinePlugin`	定义全局常量（环境变量）
`CopyWebpackPlugin`	复制静态资源到输出目录
`BundleAnalyzerPlugin`	可视化分析 bundle 体积
`TerserWebpackPlugin`	压缩 JS（生产环境默认启用）
`CssMinimizerPlugin`	压缩 CSS

5. Mode（模式）

模式	值	说明
开发模式	`development`	开启 source map，不压缩代码，构建速度快
生产模式	`production`	自动压缩代码、Tree Shaking、Scope Hoisting
无	`none`	不应用任何默认优化

6. Resolve（模块解析）

module.exports = {
  resolve: {
    // 省略后缀名的解析顺序
    extensions: ['.tsx', '.ts', '.js', '.json'],
    alias: {
      '@': path.resolve(__dirname, 'src'), // 配置路径别名
    },
  },
}

三、Loader vs Plugin 对比

💡 高频面试题： Loader 和 Plugin 的区别是什么？

维度	Loader	Plugin
本质	函数（转换器）	类（带 `apply` 方法）
作用对象	单个文件（模块级别）	整个构建过程（全局）
执行时机	模块加载阶段	Webpack 生命周期的各个钩子
配置位置	`module.rules`	`plugins` 数组
典型用途	文件格式转换	打包优化、资源注入、环境变量

四、Webpack 构建流程

Webpack 的完整构建流程可分为以下阶段：

1. 初始化（Init）
   ├─ 读取 webpack.config.js
   └─ 合并 Shell 参数，创建 Compiler 对象

2. 编译（Make）
   ├─ 从 Entry 出发，创建 Compilation 对象
   ├─ 递归解析每个模块的依赖
   └─ 对每个模块调用对应的 Loader 进行转换

3. 封装（Seal）
   ├─ 将模块组合成 Chunk
   └─ 对 Chunk 进行优化（Tree Shaking、代码分割等）

4. 输出（Emit）
   ├─ 根据 output 配置生成文件路径
   └─ 将 bundle 写入文件系统

💡 关键概念：

Compiler：Webpack 的核心对象，代表完整的配置环境，整个生命周期只有一个。

Compilation：每次构建（包括 watch 触发的重新构建）都会创建一个新的 Compilation 实例。

五、热更新（HMR）原理

Hot Module Replacement（HMR）是 Webpack Dev Server 提供的功能，允许在不刷新整个页面的情况下替换更新的模块。

文件变更
    ↓
webpack 重新编译变更模块，生成新的 chunk
    ↓
webpack-dev-server 通过 WebSocket 通知浏览器
    ↓
浏览器的 HMR Runtime 请求新的 chunk
    ↓
新模块替换旧模块，触发 module.hot.accept 回调
    ↓
局部更新，页面状态保留 ✅

// 在代码中手动接受 HMR 更新
if (module.hot) {
  module.hot.accept('./someModule', () => {
    // 模块更新后的回调逻辑
    const newModule = require('./someModule')
    // 重新渲染或处理
  })
}

六、代码分割（Code Splitting）

Code Splitting 是优化 bundle 体积、提升首屏加载速度的关键手段。

方式一：多入口（Entry Points）

// 适合 MPA，每个页面独立一个 bundle
entry: { home: './src/home.js', about: './src/about.js' }

方式二：动态导入（Dynamic Import）

// React 路由懒加载示例
import React, { lazy, Suspense } from 'react'

// Webpack 会将 About 拆分为独立的 chunk
const About = lazy(() => import('./pages/About'))

function App() {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <About />
    </Suspense>
  )
}

方式三：SplitChunksPlugin（提取公共模块）

module.exports = {
  optimization: {
    splitChunks: {
      chunks: 'all',          // 对所有 chunk 生效（包括异步和同步）
      cacheGroups: {
        vendor: {
          test: /[\\/]node_modules[\\/]/,
          name: 'vendors',    // 将 node_modules 提取为 vendors chunk
          priority: 10,
        },
        common: {
          minChunks: 2,       // 至少被 2 个 chunk 引用才提取
          name: 'common',
        },
      },
    },
  },
}

七、Tree Shaking

Tree Shaking 是删除未使用代码（Dead Code）的优化手段，依赖于 ES Module 的静态结构（import / export）。

⚠️ 注意： CommonJS（require）是动态的，无法进行静态分析，因此不支持 Tree Shaking！

// ✅ ESM 支持 Tree Shaking
export function used() { return 'I am used' }
export function unused() { return 'I will be removed' }  // 未被引用，会被移除

// 引用方
import { used } from './utils'  // unused 不会被打包进来

// package.json 中声明副作用文件（防止误删）
{
  "sideEffects": ["*.css", "*.global.js"]  // 这些文件不做 Tree Shaking
}

Tree Shaking 生效条件：

使用 ES Module 语法
mode: 'production'（Webpack 自动启用）
package.json 中正确配置 sideEffects

八、性能优化策略

构建速度优化

策略	说明
`cache: { type: 'filesystem' }`	持久化缓存，二次构建速度极快
`thread-loader`	多进程并行编译（适合耗时 Loader）
`include` / `exclude`	缩小 Loader 处理范围，排除 `node_modules`
`resolve.extensions` 精简	减少后缀名尝试次数
`esbuild-loader` 替换 `babel-loader`	Go 编写，速度极快
DLL（Webpack 4）/ 持久化缓存（Webpack 5）	预编译不变的库

Bundle 体积优化

策略	说明
Tree Shaking	移除未使用代码
Code Splitting	按需加载，减小首屏 bundle
`TerserPlugin`	压缩 JS
`CssMinimizerPlugin`	压缩 CSS
`gzip` / `brotli` 压缩	配合服务器 / `CompressionPlugin`
图片压缩	`image-minimizer-webpack-plugin`
分析工具	`webpack-bundle-analyzer` 找出体积瓶颈

// Webpack 5 持久化缓存配置
module.exports = {
  cache: {
    type: 'filesystem',                    // 文件系统缓存
    buildDependencies: {
      config: [__filename],               // 配置文件变更时使缓存失效
    },
  },
}

九、Webpack 5 新特性

新特性	说明
持久化缓存	`cache: { type: 'filesystem' }`，构建提速显著
模块联邦（Module Federation）	多个独立应用之间共享模块，微前端核心方案
资源模块（Asset Modules）	内置处理图片/字体，无需 `file-loader`/`url-loader`
更好的 Tree Shaking	支持嵌套模块、`export *` 的 Tree Shaking
移除 Node.js Polyfill	不再自动注入 `Buffer`、`process` 等 Polyfill

// Webpack 5 资源模块类型
{
  test: /\.(png|jpg|gif)$/,
  type: 'asset',              // 自动选择（< 8kb inline，否则 resource）
  // type: 'asset/resource'  // 输出为单独文件（等价 file-loader）
  // type: 'asset/inline'    // 转为 base64 data URI（等价 url-loader limit）
  // type: 'asset/source'    // 导出源代码字符串（等价 raw-loader）
}

十、模块联邦（Module Federation）

Module Federation 是 Webpack 5 的革命性特性，允许不同的 Webpack 构建之间运行时共享模块，是微前端架构的重要实现方式。

// 远程应用（remote）暴露模块
const { ModuleFederationPlugin } = require('webpack').container

// remote/webpack.config.js
new ModuleFederationPlugin({
  name: 'remoteApp',
  filename: 'remoteEntry.js',          // 暴露的入口文件
  exposes: {
    './Button': './src/components/Button', // 对外暴露 Button 组件
  },
  shared: ['react', 'react-dom'],       // 共享依赖，避免重复加载
})

// host/webpack.config.js
new ModuleFederationPlugin({
  name: 'hostApp',
  remotes: {
    // 引用远程应用
    remoteApp: 'remoteApp@http://localhost:3001/remoteEntry.js',
  },
  shared: ['react', 'react-dom'],
})

十一、Source Map 配置

Source Map 用于将打包后的代码映射回源代码，便于调试。

`devtool` 值	构建速度	重建速度	适用场景
`eval`	最快 ⚡	最快 ⚡	开发环境（行级精度）
`eval-cheap-module-source-map`	较快	较快	开发环境推荐
`source-map`	慢	慢	生产环境推荐
`hidden-source-map`	慢	慢	生产（不暴露给用户，用于错误监控）
`nosources-source-map`	慢	慢	生产（只映射行列，不暴露源码）
`false`	最快	最快	生产（无需调试时）

十二、Vite 核心知识点

1. Vite 是什么？

Vite（法语"快"）是由 Vue 作者尤雨溪开发的新一代前端构建工具，由两部分组成：

开发服务器：基于原生 ES Module（ESM），实现极速冷启动和按需编译
生产构建：基于 Rollup 进行打包，输出高度优化的静态资源

💡 核心理念： 开发环境利用浏览器原生 ESM，完全跳过打包步骤；生产环境用 Rollup 打包，兼顾性能与兼容性。

2. Vite 开发模式原理（为什么快？）

Webpack 的开发模式（Bundle-based）：

所有模块
    ↓ 递归分析依赖
    ↓ Loader 转换
    ↓ 打包成 bundle
    ↓ 启动 Dev Server
浏览器请求 bundle（项目越大，等待越久）

Vite 的开发模式（ESM-based，No Bundle）：

启动 Dev Server（几乎瞬间）
    ↓
浏览器请求某个模块（如 /src/App.vue）
    ↓
Vite 拦截请求，按需转换该模块
    ↓
返回转换后的 ESM 模块给浏览器
    ↓
浏览器解析 import，继续请求依赖模块（按需加载）

结论： Vite 的冷启动时间与项目大小几乎无关，Webpack 则随项目规模线性增长。

3. 依赖预构建（Dependency Pre-Bundling）

Vite 在首次启动时会用 esbuild（Go 编写，速度比 JS 快 10-100 倍）对 node_modules 中的依赖进行预构建，目的是：

原因	说明
CommonJS 兼容	将 CJS/UMD 格式的依赖转换为 ESM
减少请求数	将有大量内部模块的包（如 `lodash-es`）合并为单个文件
缓存优化	预构建结果缓存在 `node_modules/.vite`，依赖不变则复用

# 强制重新预构建（修改 vite.config.ts 后通常自动触发）
vite --force

4. Vite 配置文件核心选项

// vite.config.ts
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import path from 'path'

export default defineConfig({
  plugins: [react()],  // 插件列表（兼容 Rollup 插件 API）

  resolve: {
    alias: {
      '@': path.resolve(__dirname, 'src'), // 路径别名
    },
  },

  server: {
    port: 3000,       // 开发服务器端口
    open: true,       // 启动时自动打开浏览器
    proxy: {          // 代理配置（解决跨域）
      '/api': {
        target: 'http://localhost:8080',
        changeOrigin: true,
        rewrite: (path) => path.replace(/^\/api/, ''),
      },
    },
  },

  build: {
    outDir: 'dist',             // 输出目录
    sourcemap: true,            // 生产 source map
    rollupOptions: {            // 透传给 Rollup 的配置
      output: {
        manualChunks: {         // 手动分割 chunk
          vendor: ['react', 'react-dom'],
        },
      },
    },
  },

  css: {
    preprocessorOptions: {
      scss: {
        additionalData: `@import "@/styles/variables.scss";`, // 全局注入 SCSS 变量
      },
    },
  },
})

5. Vite 的 HMR（热更新）

Vite 的 HMR 基于原生 ESM，比 Webpack 更精准：

文件变更（如修改 Button.tsx）
    ↓
Vite 通过 WebSocket 通知浏览器
    ↓
浏览器仅请求并替换 Button.tsx 这一个模块
    ↓
无需重新执行整个模块图 ✅

// 手动接受 HMR（Vite 风格）
if (import.meta.hot) {
  import.meta.hot.accept('./someModule', (newModule) => {
    // 使用新模块
  })

  // 模块销毁时清理副作用（如定时器、事件监听）
  import.meta.hot.dispose(() => {
    clearInterval(timer)
  })
}

💡 差异： Vite 的 HMR 只重新请求变更的模块本身；Webpack 需要重新构建包含该模块的整个 chunk。

6. Vite 环境变量

# .env 文件（所有环境）
VITE_APP_TITLE=My App

# .env.development（仅开发）
VITE_API_URL=http://localhost:8080

# .env.production（仅生产）
VITE_API_URL=https://api.example.com

⚠️ 注意： 只有以 VITE_ 开头的变量才会暴露给客户端代码！

// 在代码中访问
console.log(import.meta.env.VITE_API_URL)
console.log(import.meta.env.MODE)    // 'development' | 'production'
console.log(import.meta.env.DEV)     // boolean
console.log(import.meta.env.PROD)    // boolean

7. Vite 插件机制

Vite 插件兼容 Rollup 插件 API，并扩展了 Vite 特有的钩子：

// 自定义 Vite 插件示例
function myPlugin() {
  return {
    name: 'my-plugin',                          // 插件名称（必须）
    enforce: 'pre',                             // 'pre' | 'post'，控制执行顺序

    // Rollup 通用钩子
    resolveId(id) { /* 自定义模块解析 */ },
    load(id) { /* 自定义模块加载 */ },
    transform(code, id) {                       // 转换模块代码
      if (id.endsWith('.txt')) {
        return `export default ${JSON.stringify(code)}`
      }
    },

    // Vite 特有钩子
    configureServer(server) {                   // 配置开发服务器
      server.middlewares.use((req, res, next) => {
        next()
      })
    },
    handleHotUpdate({ file, server }) {         // 自定义 HMR 行为
      server.ws.send({ type: 'full-reload' })
    },
  }
}

常用 Vite 插件：

插件	用途
`@vitejs/plugin-react`	React 官方支持（Babel / SWC）
`@vitejs/plugin-vue`	Vue 3 官方支持
`vite-plugin-svgr`	将 SVG 作为 React 组件导入
`unplugin-auto-import`	自动导入 API（无需手动 import）
`unplugin-vue-components`	Vue 组件自动导入
`vite-plugin-pwa`	PWA 支持
`rollup-plugin-visualizer`	bundle 体积可视化分析

8. Vite 生产构建优化

export default defineConfig({
  build: {
    // 代码分割
    rollupOptions: {
      output: {
        manualChunks(id) {
          // 将 node_modules 按包名分割
          if (id.includes('node_modules')) {
            return id.split('node_modules/')[1].split('/')[0]
          }
        },
      },
    },

    // 资源内联阈值（小于该值转为 base64）
    assetsInlineLimit: 4096,  // 默认 4kb

    // 压缩器选择
    minify: 'esbuild',        // 默认，速度最快
    // minify: 'terser',      // 压缩率更高，速度较慢

    // chunk 大小警告阈值
    chunkSizeWarningLimit: 500,  // 单位 kb
  },
})

十三、Webpack vs Vite 深度对比

核心架构对比

维度	Webpack	Vite
开发模式	Bundle-based（先打包再启动）	ESM-based（无打包，按需编译）
冷启动速度	慢（随项目规模线性增长）	极快（与项目规模几乎无关）
HMR 速度	较慢（重新构建 chunk）	极快（精确替换单个模块）
生产打包	Webpack 自身	Rollup
底层语言	JavaScript	JS + Go（esbuild 预构建）
配置复杂度	高（灵活但繁琐）	低（开箱即用，约定优于配置）
插件生态	极其丰富，成熟稳定	快速发展，兼容 Rollup 插件
TypeScript	需配置 `ts-loader`	原生支持（仅转译，不类型检查）
CSS 处理	需配置 Loader	原生支持 CSS/SCSS/Less
旧浏览器兼容	强（可配置降级至 IE11）	默认仅支持现代浏览器（ES2015+）
微前端支持	Module Federation（原生）	需插件（`@originjs/vite-plugin-federation`）

开发体验对比

场景	Webpack	Vite
初次启动（大型项目）	30s ~ 数分钟	< 1s
HMR 响应时间	数百ms ~ 数秒	< 50ms
配置学习曲线	陡峭	平缓
开箱即用程度	低（需大量配置）	高（零配置可运行）
调试体验	需手动配置 source map	默认开启

适用场景对比

场景	推荐	理由
新项目（现代浏览器）	Vite	开发体验好，上手快
需要兼容 IE11	Webpack	Vite 默认不支持旧浏览器
微前端架构（Module Federation）	Webpack	原生支持，成熟稳定
超大型遗留项目迁移	Webpack	生态兼容性更强
追求极致开发速度	Vite	HMR 和冷启动碾压级优势
Library / 工具库开发	Vite	内置 Library 模式，配置简洁

💡 面试结论： Vite 不是 Webpack 的替代品，而是在现代浏览器环境下提供了更好的开发体验。两者核心思路不同：Webpack 是"先打包再服务"，Vite 是"先服务再按需编译"。

十四、高频面试题 Q&A

Q1: Webpack 如何实现懒加载？

通过动态 import() 语法，Webpack 会自动将对应模块拆分为独立 chunk，在运行时按需加载。

// Webpack 识别到动态 import，自动代码分割
button.addEventListener('click', async () => {
  const { default: module } = await import('./heavyModule')
  module.doSomething()
})

Q2: 如何分析 bundle 体积？

# Webpack
pnpm add -D webpack-bundle-analyzer

# Vite
pnpm add -D rollup-plugin-visualizer

// Webpack
const { BundleAnalyzerPlugin } = require('webpack-bundle-analyzer')
plugins: [new BundleAnalyzerPlugin()]

// Vite（vite.config.ts）
import { visualizer } from 'rollup-plugin-visualizer'
plugins: [visualizer({ open: true })]

Q3: hash / chunkhash / contenthash 的区别？

类型	变化时机	推荐用途
`hash`	任意文件变更，所有 bundle 的 hash 都变	不推荐
`chunkhash`	同一 chunk 中任意模块变更	JS 文件
`contenthash`	仅当文件自身内容变更	CSS 文件、长缓存最佳实践

Q4: Vite 为什么开发环境快，生产环境还要用 Rollup？

开发环境快的原因： 利用浏览器原生 ESM，完全跳过打包，按需编译，启动时间与项目规模无关。

生产环境使用 Rollup 的原因：

原因	说明
Tree Shaking	Rollup 对 ESM 的 Tree Shaking 比原生 ESM 更彻底
代码分割优化	浏览器请求过多小模块会影响性能，需要合理打包
兼容性	部分环境不完全支持原生 ESM
压缩优化	需要对代码进行混淆、压缩

⚠️ 注意： 开发和生产使用不同工具（esbuild vs Rollup），可能导致开发与生产环境行为不一致，这是 Vite 已知的权衡点。

Q5: Vite 如何处理 CommonJS 依赖？

Vite 在预构建阶段用 esbuild 将 CJS 格式的 node_modules 依赖转换为 ESM，因此业务代码中可以正常 import CJS 包：

// 这在 Vite 中可以正常工作，因为 lodash 会被预构建为 ESM
import _ from 'lodash'

// 如果某个包未被正确预构建，手动指定
export default defineConfig({
  optimizeDeps: {
    include: ['some-cjs-package'], // 强制预构建
  },
})

🚨 面试总结提示： 面试时不要只背概念，要结合实际项目经验来回答。例如"我们团队把老项目从 Webpack 迁移到 Vite，冷启动从 45 秒降到了 2 秒"，或"我在 Webpack 项目中配置 splitChunks 提取 vendors，首屏减少了 40%"，这类具体案例会更有说服力。