Webpack核心原理与打包优化实战：从配置到面试全覆盖

Webpack这几年一直处于“人人都用，但很多人只会复制配置”的状态。不少前端同学在简历里写着“熟练使用Webpack”，真到要自己搭一个配置、优化一次打包体积、或者面试被问到“Webpack是怎么工作的”时，就愣住了。这篇博文我想从基础原理讲起，再落到一份完整可用的配置，然后聊聊打包优化的几个实操方向，最后把Webpack和Vite的选型问题、以及面试里高频出现的题目一起梳理一遍。无论是刚接触前端构建工具的新手，还是用了很久配置却不太清楚原理的开发者，都可以照着思路走一遍。

1. 先搞清楚：Webpack到底解决了什么问题

1.1 前端模块化的历史包袱

在Webpack出现之前，前端代码的组织方式非常原始。页面里写多个<script>标签，靠全局变量互相通信，顺序错了就报错，同名了就被覆盖。后来有了AMD、CMD、CommonJS这些模块规范，浏览器端却只能部分支持，开发者需要借助RequireJS、SeaJS这类库才能跑起来。这种“能用但别扭”的状态，本质上是因为浏览器缺乏原生的模块能力。

Webpack的核心价值就是把这一切抹平。它做的事情可以概括成一句话：**把各种形式的资源——JS、CSS、图片、字体，甚至文本和JSON——当作模块，统一打包成浏览器能直接运行的静态文件。**它的名字很形象，“Web”指Web场景，“pack”意即打包，合起来就是“为Web打包”。

1.2 核心概念其实只有五个

理解Webpack不需要背一堆术语，抓住五个核心概念，后面所有配置都围着它们转：

• Entry（入口）：打包从哪个文件开始。Webpack会顺着这个文件的import语句，把所有依赖关系找出来。
• Output（出口）：打包结果输出到哪里，文件名怎么生成。
• Loader（加载器）：Webpack本身只认识JS和JSON，Loader负责把其他类型的文件“翻译”成Webpack能识别的模块。比如babel-loader把ES6+语法转成ES5，css-loader把CSS处理成JS模块。
• Plugin（插件）：Loader解决文件转换，Plugin解决更广的问题——打包后文件的压缩、环境变量的注入、HTML模板生成、打包进度展示等。
• Mode（模式）：设置development、production或none，Webpack会自动启用或关闭一系列内置优化。

这个模型可以用一个生活化的类比来记：入口是原材料进厂的传送带，Loader是车间里的工人，把不同形态的原料加工成标准零件，Plugin是工厂的管理系统，负责质检、包装、物流调度，出口就是成品出厂的仓库大门。整个流水线就是一张依赖关系图，Webpack负责调度和执行。

2. 从零手写一份Webpack配置

2.1 最小可用配置长什么样

先别管复杂的工程化脚手架，我们自己动手初始化一个项目，从零配置最有感觉。新建一个目录，执行：

bash复制npm init -y
npm install webpack webpack-cli --save-dev

然后创建src/index.js，写点最简单的逻辑：

javascript复制const element = document.createElement('div');
element.innerHTML = 'Hello Webpack';
document.body.appendChild(element);

根目录新建webpack.config.js，写入：

javascript复制const path = require('path');

module.exports = {
  entry: './src/index.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'bundle.js'
  },
  mode: 'development'
};

在package.json里加一个脚本：

json复制"scripts": {
  "build": "webpack"
}

执行npm run build，你会发现dist/bundle.js生成了。打开dist/index.html，手动引用bundle.js，就能看到页面渲染出“Hello Webpack”。这就是Webpa