从源码到上线：一个老前端的Webpack回炉记

上个月，我终于递了离职申请。在这家公司待了三年多，代码写了不少，头发掉得更多。最近面试了几家，发现不少团队已经开始用Vite、Turbopack甚至自研构建工具了，但Webpack依然是大多数中大型项目的“祖传配置”。为了不被时代甩得太远，也为了给下一份工作攒点底气，我决定重新啃一遍Webpack——这次不是走马观花，而是从零搭起一个可落地的工程化脚手架。

说来惭愧，虽然天天喊“工程化”，但以前在公司里都是直接git clone老项目，改两行业务代码就跑路。直到上周五晚上，产品经理突然在群里@我：“新活动页下周三上线，要支持SSR和按需加载，对了，还得兼容IE11（别问，问就是金融客户）。” 我盯着屏幕，手里的冰美式瞬间不香了——这需求，妥妥的“既要又要还要”三件套。

为什么还要学Webpack？

你可能会问：“都2024年了，还折腾Webpack？Vite不香吗？”
确实，Vite启动快如闪电，HMR秒级响应，但现实是——很多存量项目根本没法迁移。我们组去年就想切Vite，结果光是处理那些魔改的loader和插件就卡了两个月，最后还是被线上一个诡异的chunk split bug劝退。运维大哥还吐槽：“你们前端天天换工具，我们的CI/CD流水线都要重写十遍了！”

所以，与其抱怨，不如把Webpack玩明白。毕竟，理解底层原理，才能在任何工具链里游刃有余。而且，翻GitHub上那些明星开源项目（比如Next.js、Nuxt），你会发现它们底层依然重度依赖Webpack的模块机制和插件生态。

从零开始：别再复制粘贴了

我拉了个新目录，执行npm init -y，然后装了最基础的包：

npm install webpack webpack-cli webpack-dev-server --save-dev

注意！这里没装webpack-dev-server的v5，而是v4.15.1——因为v5对Node.js版本要求太高，而我们公司的构建机还在用Node 14（别问，问就是“稳定压倒一切”）。这种细节，只有踩过坑才懂。

接下来，我建了最简配置 webpack.config.js：

const path = require('path');

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

运行 npx webpack，成功生成dist/bundle.js。但当我打开浏览器，控制台报错：Uncaught ReferenceError: process is not defined。啊，对了！Webpack 5默认不再自动注入Node.js的全局变量。赶紧补上：

// webpack.config.js
module.exports = {
  // ...
  resolve: {
    fallback: {
      "process": require.resolve("process/browser")
    }
  },
  plugins: [
    new webpack.ProvidePlugin({
      process: 'process/browser',
    })
  ]
}

这种“祖传bug”，文档里往往一笔带过，但GitHub issue里全是血泪。建议大家遇到问题先搜issue，别死磕官方文档。

实战：搞定CSS和图片资源

业务代码里肯定不止JS。我新建了src/style.css，并在index.js里import './style.css'。结果打包报错：You may need an appropriate loader to handle this file type。

老规矩，装loader：

npm install css-loader style-loader --save-dev

配置：

module.exports = {
  // ...
  module: {
    rules: [
      {
        test: /\.css$/,
        use: ['style-loader', 'css-loader']
      }
    ]
  }
}

注意顺序！loader是从右往左执行的，所以css-loader先解析CSS，style-loader再把结果注入DOM。这个顺序我当年面试被问过三次，至今记忆犹新。

接着处理图片。用户上传的头像、活动banner……这些都得打包。装file-loader（虽然现在官方推荐asset modules，但为了兼容旧项目，我还是先用熟悉的）：

{
  test: /\.(png|svg|jpg|jpeg|gif)$/i,
  type: 'asset/resource',
  generator: {
    filename: 'images/[name].[hash][ext]'
  }
}

这里用asset/resource替代了file-loader，是Webpack 5的新特性。生成的文件会自动放到dist/images/下，路径带hash防缓存。上线前再也不用求运维清CDN了！

开发体验优化：HMR和代理

每次改代码都要手动刷新？达咩！开启热更新：

// webpack.config.js
devServer: {
  hot: true,
  open: true,
  proxy: {
    '/api': {
      target: 'http://localhost:3001',
      changeOrigin: true
    }
  }
}

proxy配置解决了本地开发时的跨域问题。以前我们组经常因为这个和后端吵——“你们接口怎么又没加CORS头？”“前端自己配代理啊！” 现在，一行配置，世界和平。

但HMR有个坑：默认只对CSS生效，JS模块需要手动accept。我在index.js里加了：

if (module.hot) {
  module.hot.accept();
}

不过更推荐用框架自带的HMR方案（比如React Fast Refresh），否则状态会丢失。这点在复杂表单页面尤其致命——填了半天信息，一改代码全没了，用户能骂你三天。

生产构建：压缩、分包、兼容性

开发爽了，上线不能翻车。切换到生产模式：

// webpack.prod.js
const TerserPlugin = require('terser-webpack-plugin');
const CssMinimizerPlugin = require('css-minimizer-webpack-plugin');

module.exports = {
  mode: 'production',
  optimization: {
    minimizer: [
      new TerserPlugin(),
      new CssMinimizerPlugin()
    ],
    splitChunks: {
      chunks: 'all',
      cacheGroups: {
        vendor: {
          test: /[\\/]node_modules[\\/]/,
          name: 'vendors',
          chunks: 'all',
        }
      }
    }
  }
}

关键点：

• 代码分割：把第三方库（如React、Lodash）拆成vendors.js，利用浏览器缓存，用户下次访问只加载变动的业务代码。
• 压缩：Terser压JS，CssMinimizer压CSS，体积直降60%。
• 兼容IE11：虽然恶心，但需求就是需求。装core-js和regenerator-runtime，在入口文件顶部加：

import 'core-js/stable';
import 'regenerator-runtime/runtime';

再配合Babel的@babel/preset-env，指定targets: { ie: '11' }，至少能跑起来（虽然性能感人）。

调试技巧：Source Map和Bundle分析

线上出Bug，总不能靠console.log定位吧？Source Map必须开：

// 开发环境
devtool: 'eval-source-map',
// 生产环境（谨慎！）
devtool: 'source-map'

注意：生产环境开Source Map有安全风险，建议只在测试环境开启，或通过权限控制访问。

另外，用webpack-bundle-analyzer看看包体积：

npm install --save-dev webpack-bundle-analyzer

const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;

plugins: [
  new BundleAnalyzerPlugin()
]

运行后自动打开浏览器，可视化各模块大小。上次我发现一个不起眼的日期库居然占了200KB，换成dayjs后，首屏加载快了1.2秒——产品经理当场给我点了奶茶。

GitHub上的宝藏

整个过程我参考了几个超棒的GitHub项目：

• webpack/webpack：官方仓库，issue区是宝藏
• survivejs/webpack：《SurviveJS - Webpack》书配套代码，深入浅出
• vuejs/vue-cli：看大厂怎么封装Webpack配置

特别是SurviveJS，作者把每个loader和plugin的原理都讲透了，比官方文档友好一万倍。

写在最后

折腾完这套配置，我不仅搞定了那个“既要又要还要”的活动页，还顺手给团队出了个内部培训。运维大哥看到构建时间从8分钟降到3分钟，破天荒请我吃了顿火锅。

其实，工程化工具没有银弹，只有适合当下场景的权衡。Webpack可能不够快，但它的生态和灵活性，在复杂项目中依然是不可替代的。作为即将跳槽的“老”前端，我深知：能解决问题的技术，才是好技术。

如果你也在试用期，或者正准备换工作，不妨花几天时间，亲手搭一次Webpack。别怕踩坑，每个坑都是简历上的一行亮点。毕竟，面试官最爱问：“你遇到过哪些Webpack相关的问题？怎么解决的？”

（完）

附：完整配置已上传GitHub，欢迎Star和提Issue：github.com/yourname/webpack-from-scratch
P.S. 别真点链接，这是示例 😅