打开任何一个现代前端项目的根目录，你大概率会看到一个叫 webpack.config.js 的文件。它像一张施工图纸，安静地躺在那里，但整个项目的运转都绕不开它。webpack 是什么？一句话：它是一个模块打包器。但这句话太干了，跟没说一样。我更愿意把它比作一个极度较真的搬运工——你告诉它入口在哪，它就顺着入口把项目里所有文件（JS、CSS、图片、字体）都翻出来，然后按你的要求重新整理、打包，最后吐出一个或几个浏览器能直接跑的文件。

为什么需要这个搬运工？2012 年前后，前端项目开始变得不像话。以前一个页面挂几个 script 标签就完事，后来不行了。模块化开发成了标配，你写 import _ from 'lodash' 的时候很爽，但浏览器不认识这个语法。还有 Sass、TypeScript、JSX，这些浏览器统统不认。更别提图片要压缩、代码要拆分、开发时要热更新。这些事如果手动做，一个中型项目能把你逼疯。webpack 的价值就在于，它把这些脏活累活全接过去，你只管写代码，剩下的它来。

它的工作流程其实不复杂。从你指定的入口文件开始，比如 src/index.js，webpack 会递归地分析所有依赖。遇到 import 就追进去，遇到 require 也追进去，像剥洋葱一样一层层剥开。每个文件经过 loader 处理——loader 就是转换器，把 SCSS 变成 CSS，把 ES6 变成 ES5，把 JSX 变成普通 JS。处理完的模块被组织成一个依赖图，最后根据配置输出到 dist 目录。整个过程像一条流水线，原料进去，成品出来。

我印象很深的一个细节是 webpack 的配置文件。第一次看的时候觉得头大，entry、output、module.rules、plugins，一堆概念堆在一起。但用久了会发现，它其实很直白。entry 就是告诉它从哪开始，output 是告诉它成品放哪，rules 是告诉它遇到什么文件用什么工具处理，plugins 则是干一些 loader 干不了的活，比如生成 HTML、清理目录、提取 CSS。你配置一次，之后每次构建都按这个规矩来。这种确定性让人安心。

当然，webpack 不是没有槽点。配置复杂是出了名的，一个稍微像样的项目，配置文件能写到两三百行。而且它的构建速度在项目变大后会明显变慢，改一行代码等好几秒才热更新，那种感觉像在等一个慢性子的人回消息。后来 Vite 出来了，用 esbuild 做预构建，开发时几乎秒开，很多人转头就换了。但 webpack 的生态太厚了，插件和 loader 的数量是其他工具没法比的。很多老项目、企业级项目还在用它，不是不想换，是换的成本太高。

我自己用 webpack 最频繁的场景是处理多页面应用。每个页面一个入口，配合 html-webpack-plugin 自动生成对应的 HTML，splitChunks 把公共依赖抽出来。这套组合拳打下来，构建产物干净利落，浏览器缓存也友好。有一次我试着不用 webpack，手动用 gulp 拼了一套流程，结果光是处理 CSS 里的图片路径就折腾了一下午。那一刻我承认，webpack 的抽象虽然重，但它确实把复杂度封装起来了。

说到底，webpack 是一个时代的产物。它解决了前端工程化最混乱时期的核心问题：模块依赖和资源转换。它不完美，配置繁琐，构建慢，但它的设计思路——一切皆模块、依赖图驱动、loader 和 plugin 双轨制——影响了后来几乎所有的构建工具。你甚至可以在 Vite 的文档里看到 webpack 的影子。所以哪怕你不用它了，理解它仍然有价值。它像一座老桥，你未必天天走，但知道它怎么架起来的，对你理解河流的走向有帮助。