Webpack 的名字前端圈子里几乎没人不认识。但“认识”和“用熟”之间隔着一条需要自己亲手走过的路。从最早的 gulp、grunt到如今的 Vite 满天飞Webpack 依然占据着大量企业级项目的构建席位原因很简单它足够底层、足够灵活也足够成熟。这篇实战笔记我会用一个真实项目的搭建过程把 Webpack 从入门到实战、从基础配置到打包优化全流程梳理一遍顺便把手里的那些坑和心得一并倒给你。无论你是刚接触前端工程化的新人还是被 webpack 配置优化搞得焦头烂额的老手都可以在这里找到可直接复用的方案。1. 为什么前端工程化离不开 Webpack1.1 从手动管理脚本到模块化构建的痛点一开始写前端可能就是把几个 JS 文件用 script 标签挨个引进去。文件少的时候还好一旦项目大起来痛点就非常明显脚本加载顺序决定了运行成败稍不注意就报 “xxx is not defined”。所有变量默认落在全局作用域互相污染是家常便饭。想用 npm 生态里的第三方库得手动下载文件、维护版本更新一次全项目心惊胆战。写了 ES Module 语法浏览器兼容性不统一还得想各种办法做转换。这些问题本质上是“依赖关系没有自动化管理”。Webpack 解决的正是这件事它把项目当成一张依赖图从一个入口开始顺着代码里的 import/require 把所有依赖找全、找齐再按规则转换成浏览器能懂的静态资源。你可以把 Webpack 看作一条全自动流水线原料是无数个分散的模块文件产出是经过合并、压缩、优化后的最终静态文件。这一过程就是前端工程化的核心基础。1.2 Webpack 在整个工具链里的定位前端工程化工具已经非常多元化。gulp、grunt 偏任务流适合批量处理文件Rollup 擅长库打包产出干净Esbuild 以极快速度出圈Vite 在开发体验上一骑绝尘。那 Webpack 为什么还是主角关键在三个点生态、可控性、企业存量。生态loader 和 plugin 的数量和质量几乎没有对手遇到再偏门的场景基本能找到现成方案。可控性配置项粒度极细好习惯和坏习惯都在配置里表现得明明白白。这对大型团队来说尤其重要。企业存量大量中大型项目的构建体系都建立在 Webpack 之上看懂它等于看懂了那些项目的构建核心。不是说它完美无缺而是它的地位和适用面决定了它依然是前端进阶绕不开的一道门槛。把它学透再去看 Vite、Turbopack你会发现很多概念都是相通的——无非是底层实现不同、配置形态不同而已。1.3 学习 Webpack 的最佳路径这也是我最想提醒新人的一点不要一上来就背配置。我见过太多人记了一大堆配置项转头就忘。正确路径应该是——先手动搭建一个最简项目把入口、输出、loader、plugin 跑通再逐步加入优化手段每一步都观察打包产物的变化。只有理解了“为什么这么配”配置才不会成为负担。后面几章我就是按这条路径来带大家走一遍的。2. 核心概念与工作原理2.1 入口、输出与依赖图Webpack 有四个最核心的概念入口entry、输出output、加载器loader、插件plugin外加一个模式mode。先看入口和输出。入口是 Webpack 开始解析依赖时的起点文件在 config 中用 entry 指定。最常见的写法module.exports { entry: ./src/index.js, output: { path: path.resolve(__dirname, dist), filename: bundle.js } };当 Webpack 拿到入口后会扫描该文件中所有 import 语句找到依赖模块接着再递归扫描这些模块的依赖直到把所有关联文件都找出来。最终每个模块之间的引用关系会被组织成一张“依赖图”。这张图是 Webpack 后续所有工作的基础。关于输出有几个容易忽略的细节output.path 必须是绝对路径。filename 可以带目录比如 js/bundle.js产物会自动放入对应子目录。如果项目同时输出多个入口filename 常用 [name] 占位符[name] 会被替换为 entry key 的名字。2.2 Loader 与 Plugin一个负责转换一个负责加工这两个概念是新手最容易混淆的。我用一句话区分loader 负责把文件转成 Webpack 能处理的模块plugin 负责处理模块之后更宏观的事情。具体来说Webpack 本身只能理解 JavaScript 和 JSON 文件。项目里的 CSS、图片、字体、TypeScript、Vue 组件等Webpack 都不认识。loader 的作用就是把它们翻译成 Webpack 认识的模块。比如 css-loader 可以把 CSS 解析成字符串style-loader 再把样式注入到 DOM。plugin 则不同。它在 Webpack 生命周期里提供了各种钩子可以做 loader 做不了的事生成 HTML、压缩代码、提取公共代码、拷贝静态资源、监控构建进度等。如果把打包过程比作工厂流水线loader 是车间里一个个加工工位plugin 则是整条产线的调度和质检系统。常用 loader 和 plugin 见后面配置示例但先记住这个原则模块转换找 loader全局任务找 plugin。2.3 Mode 与内置优化mode 是 Webpack 4 之后引入的配置取值有 development、production、none。很多人只把它当“环境标识”实际上它会自动开启一系列内置优化。development开启 eval 类型的 Source Map设置 process.env.NODE_ENV 为 development并通过模块 ID 可读化让编辑器显示清晰。production自动开启压缩比如 terser-webpack-plugin开启 Tree Shaking生成 chunk 时做更激进的拆分设置 NODE_ENV 为 production。none不开启任何默认优化。所以你会发现很多人随手写一个 production 配置什么都没做打包体积却比 development 小很多原因就在这里。理解 mode 的机制才能在排查“为什么配置没生效”时快速定位是环境问题还是配置问题。3. 从零搭建一个完整的 Webpack 项目3.1 初始化项目与安装依赖先建目录、初始化 npmmkdir webpack-demo cd webpack-demo npm init -y接着安装基础依赖npm install webpack webpack-cli -Dwebpack-cli 提供了命令行入口没有它npx webpack 是跑不起来的。示例和配置涉及到的依赖后面按需补齐。3.2 最简配置入口、出口、模式新建 src/index.jsconst heading document.createElement(h1); heading.textContent Hello Webpack; document.body.appendChild(heading);新建 webpack.config.jsconst path require(path); module.exports { entry: ./src/index.js, output: { path: path.resolve(__dirname, dist), filename: bundle.js }, mode: development };这里先不追求优化目的就是把流程跑通。此时在 package.json scripts 里加一条scripts: { build: webpack }运行 npm run build到 dist 目录查看 bundle.js再用浏览器打开 dist/index.html需要手动建一个能看到页面正常渲染。这个最小闭环建议每个新手都亲手动一次理解了整个过程后面所有优化都是在这个基础上做增量。3.3 接入 loader处理样式、图片、字体为了让项目真正可用需要处理样式资源和图片。安装npm install style-loader css-loader -D配置module: { rules: [ { test: /\.css$/i, use: [style-loader, css-loader] } ] }注意 loader 的执行顺序数组从右往左执行。css-loader 先把 CSS 解析成 JS 模块style-loader 再将样式通过