请写一篇关于【现代前端工程化入门：Webpack基础教程】的技术文章
作者：老张，30岁，在职程序员，老家远程办公，正在备考公务员。目标：上岸体制内，告别996。
开头：一场“简历危机”引发的技术补课
去年十月的一个晚上，我正瘫在老家客厅的沙发上刷知乎，老婆在厨房切萝卜准备炖汤（没错，我已经回老家半年了，房租省了3500/月，幸福感飙升）。手机突然震动，是猎头发来的一条消息：
“张哥，有个急单，22K起，要求熟悉前端工程化、Webpack优化、微前端架构……你简历上写了‘熟练使用Webpack’，方便聊聊吗？”
我心头一热——22K！比我现在15K的远程岗高了快一半！但下一秒冷汗就下来了。
我哪会什么Webpack优化啊！
我简历上写的“熟练使用Webpack”，其实只是跑过 npm run build，改过几次 publicPath，连 loader 和 plugin 的区别都说不利索。要是真去面试，HR随便问一句“怎么实现按需加载”或者“Tree Shaking原理是什么”，我当场就得露馅。
那天晚上我没睡好。不是因为钱，而是因为焦虑——作为一个想考公但又不敢裸辞的打工人，技术栈一旦掉队，简历立马贬值。万一考公失败，我还得靠这口饭吃啊！
于是第二天一早，我对老婆说：“从今天开始，我要系统学一遍 Webpack。不为跳槽，就为把简历上的‘熟练’俩字，说得理直气壮。”
她白了我一眼：“你上次说要学 Docker，结果三天热度，现在还在用 FTP 传文件呢。”
我：“……这次不一样！”
起步：Webpack到底是个啥？别被名字吓到
说实话，一开始我对 Webpack 有心理阴影。总觉得它是个庞然大物，配置复杂得像写毕业论文。但真正沉下心来看，发现它本质上就干一件事：
把一堆乱七八糟的资源（JS、CSS、图片、字体等），打包成浏览器能跑的静态文件。
就这么简单！
以前我们写前端，HTML 引 JS，JS 引 CSS，图片直接放 img 标签里——那是“手工作坊时代”。而 Webpack 就像是一个自动化流水线工厂，你把原材料（源代码）扔进去，它给你吐出成品（dist 文件夹）。
我拿自己做的一个小项目练手：一个待办事项（Todo List）应用。没有框架，纯 HTML + JS + SCSS。以前我都是手动拼接，现在试试用 Webpack 打包。
第一步：初始化项目
mkdir webpack-todo && cd webpack-todo
npm init -y
npm install --save-dev webpack webpack-cli
然后新建 src/index.js，写点简单逻辑：
console.log('Hello, Webpack!');
再搞个 webpack.config.js：
const path = require('path');
module.exports = {
entry: './src/index.js',
output: {
filename: 'bundle.js',
path: path.resolve(__dirname, 'dist')
}
};
跑一下：
npx webpack
啪！dist/bundle.js 出来了。打开一看，除了我的 console.log，还有一堆 Webpack 自己加的运行时代码——但它确实能跑！
那一刻我悟了：Webpack 不是魔法，它只是个工具。你喂它入口，它吐你出口。
进阶：处理各种“资源”，才是工程化的开始
光打包 JS 没意思。真正的前端项目里，资源五花八门：CSS、图片、字体、JSON、甚至 Markdown。
这时候就要用到 Webpack 的两大神器：Loader 和 Plugin。
- Loader：负责“翻译”非 JS 文件。比如把 SCSS 编译成 CSS，把 TS 编译成 JS。
- Plugin：负责“做事情”。比如压缩代码、生成 HTML、清理旧文件。
场景1：我想用 SCSS 写样式
装两个 loader：
npm install --save-dev sass-loader sass css-loader style-loader
配置：
module.exports = {
// ...
module: {
rules: [
{
test: /\.scss$/,
use: ['style-loader', 'css-loader', 'sass-loader']
}
]
}
};
注意顺序！Webpack 的 loader 是从右往左执行的。所以先 sass-loader 把 SCSS 变 CSS，再 css-loader 处理 @import 和 url()，最后 style-loader 把 CSS 插入 <style> 标签。
我在 index.js 里加一句：
import './styles/main.scss';
搞定！刷新页面，样式生效了。
场景2：图片和字体怎么处理？
以前我们手动把图片扔到 public 文件夹，现在可以让 Webpack 自动处理。
npm install --save-dev file-loader url-loader
配置：
{
test: /\.(png|jpg|gif|woff|woff2)$/,
use: [
{
loader: 'url-loader',
options: {
limit: 8192, // 小于8KB的转成base64
name: '[name].[hash:8].[ext]',
outputPath: 'assets/'
}
}
]
}
这样，只要在 JS 或 CSS 里引用图片：
import logo from './logo.png';
const img = new Image();
img.src = logo;
document.body.appendChild(img);
Webpack 会自动把图片复制到 dist/assets/，并且给它重命名加 hash（防缓存），小图还会转成 base64 内联——完全不用操心路径问题！
那一刻我惊呆了：原来前端工程化，就是把“脏活累活”都交给工具，开发者只管写业务逻辑。
实战：优化打包，让简历不再“注水”
学会了基础配置，但离“熟练”还差得远。面试官如果问我：“你们项目首屏加载 5 秒，你怎么优化？” 我总不能说“换个宽带”吧？
于是我又啃了几篇官方文档和掘金高赞文章，总结出几条最佳实践，亲测有效：
1. 代码分割（Code Splitting）
默认情况下，Webpack 会把所有代码打包成一个 bundle.js。用户访问首页，却要下载整个应用的代码——太浪费了！
解决方案：动态 import + SplitChunksPlugin
// 路由懒加载
const Home = () => import('./pages/Home.vue');
const About = () => import('./pages/About.vue');
配合 optimization.splitChunks：
optimization: {
splitChunks: {
chunks: 'all',
cacheGroups: {
vendor: {
test: /[\\/]node_modules[\\/]/,
name: 'vendors',
chunks: 'all'
}
}
}
}
效果：第三方库（如 Vue、Lodash）被打包成 vendors.js，业务代码单独打包。用户第一次进首页，只加载必要的 chunk，速度提升明显。
2. Tree Shaking：干掉没用的代码
我司项目用了 Lodash，但只用了 _.debounce。结果整个 Lodash 库都被打包进去了！
解决办法：确保你的代码是 ES Module（不能用 require），然后 Webpack 会自动做 Tree Shaking。
// ✅ 正确：支持 Tree Shaking
import debounce from 'lodash/debounce';
// ❌ 错误：整包引入
import _ from 'lodash';
另外，在 package.json 里加上：
{
"sideEffects": false
}
告诉 Webpack：这个包没有副作用，没用的代码可以放心删。
实测：一个 500KB 的 bundle，优化后只剩 320KB，首屏加载快了 1.2 秒！
3. 生产环境 vs 开发环境
千万别用同一套配置跑开发和上线！我早期就犯过这错——开发时开了 source map，结果上线忘了关，用户能直接看到我的源码……
正确做法：拆成 webpack.dev.js 和 webpack.prod.js，用 webpack-merge 合并公共配置。
开发环境注重体验：HMR（热更新）、详细的错误提示、source map。
生产环境注重性能：压缩、去 console、关闭 devtool。
// webpack.prod.js
const TerserPlugin = require('terser-webpack-plugin');
module.exports = merge(common, {
mode: 'production',
optimization: {
minimizer: [new TerserPlugin({ extractComments: false })]
},
devtool: false // 关闭 source map
});
转折：从“应付面试”到“真正理解”
学了一个月，我不仅能答上面试官的问题，还在公司内部做了次技术分享。
上周五晚上，团队 Zoom 会议，我主讲《Webpack 工程化实战：从零到优化》。同事小李听完后说：“原来 loader 和 plugin 是这么回事！我一直以为它们是一个东西。”
我笑了：“我三个月前也这么以为。”
那次分享后，老大拍我肩膀：“老张，你最近进步很大啊。要不要牵头重构下我们那个老项目？”
我婉拒了——不是不想干，而是心里清楚：我的重心已经不在这里了。
我现在每天早上 7 点起床，先刷 2 小时行测，下午写代码维持生计，晚上复盘错题。考公是我今年的主线任务，技术只是保底手段。
但正因为这段“被迫深入”的经历，我反而对前端工程化有了敬畏心。工具不会淘汰人，但不懂工具的人会被淘汰。
总结：技术是手段，不是目的
写到这里，我想说几句掏心窝子的话：
如果你和我一样，是个想跳出互联网大厂、追求稳定生活的程序员，请别把技术当成负担。把它当作你上岸前的“护城河”。
- 简历上的每一个“熟练”，都应该经得起拷问；
- 每一次技术分享，都是对自己知识的加固；
- 每一项工程化能力，都是你在自由职业或远程办公时的底气。
我在老家的日子很平静：早上陪爸妈买菜，下午 coding，晚上和老婆散步。没有 PUA，没有周报，没有凌晨三点的线上事故。但我知道，这份平静背后，是我还能靠技术吃饭的自信。
所以，别怕学 Webpack，别怕配 Babel，别怕看源码。这些看似枯燥的东西，终有一天会成为你选择生活的筹码。
最后：给正在读这篇文章的你
如果你也在备考、在焦虑、在怀疑自己是不是该继续写代码——我想告诉你：
技术不会背叛你，只要你认真对待它。
Webpack 只是一个起点。后面还有 Vite、Rollup、Rspack……但万变不离其宗：理解资源如何被处理，代码如何被优化，工程如何被组织。
把这些搞懂了，你不仅能写出更好的简历，更能拥有说“不”的自由。
共勉。
—— 老张，于老家书房，窗外正下着小雨，2024年4月。
评论 0