Will.liu1. 为什么工程化搭建要选webpack5
说实话，现在前端社区天天有新工具冒出来，很多人觉得webpack已经“过时”了，vite不香吗？但你去大厂看看核心业务线，尤其是有大量历史包袱、多团队协作、需要深度定制的项目，webpack依然占据绝对主导地位。原因很简单：它的生态成熟度、插件体系的完善程度、社区踩坑量积累，不是哪个新工具一年两年能追上的。
webpack5作为一次大版本升级，跟webpack4相比，核心变化集中在持久化缓存、资源模块、模块联邦这几个点上。其中持久化缓存是实打实的构建性能提升——配置得当的情况下，二次构建能快70%以上，这对一个日构建几十次的前端项目来说，体感差别是非常明显的。
我把话放在这里：对于需要完整掌控构建流程、需要定制化工程能力的团队，webpack5不是“老古董”，而是目前前端工程化的最优解之一。它解决的问题是系统性的：模块打包、代码分割、资源优化、环境适配、开发体验、性能指标，一套体系全给你覆盖全。
这篇文章不是讲API文档，是我基于webpack5从零搭建完整前端工程化体系的一次实战记录，涵盖从目录设计、核心配置、开发服务器到多环境构建的全流程，且会把配置背后“为什么这么做”的逻辑一并讲清楚，适合正在从webpack4升级、或者打算把手动搭建和脚手架并存的项目示例参考的团队和初中级前端开发者。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. webpack5的升级要点与选型逻辑
2.1 核心升级点解析
先聊一下我优先选择webpack5而不是继续用webpack4的几个理由，这涉及实际工程效益。
第一是持久化缓存（filesystem cache）。webpack5提供了内置的cache功能，设置cache: { type: 'filesystem' }之后，编译结果会缓存在node_modules/.cache目录下。这意味着第二次构建时，没有变动的模块直接从磁盘缓存读取，跳过完整的解析和编译过程。实测一个200多个模块的项目，冷启动大概10秒，配置持久化缓存后热构建降到2-3秒，很顶。
第二是资源模块（Asset Modules）。webpack4时代我们处理图片、字体、音视频，需要配url-loader、file-loader、raw-loader这一堆loader。webpack5直接内置了asset/resource、asset/inline、asset/source和asset，不用再装那么多依赖了。这点在升级项目时的收益非常直接——依赖数量减少，配置项也精简了。
第三是模块联邦（Module Federation）。这个能力在微前端架构中非常好用，允许不同的webpack构建产物之间在运行时共享依赖和模块。我现在手头这个中后台项目就是用了模块联邦把公共组件库单独抽成一个远程包，业务代码按需加载，更新公共组件库不需要重发所有业务应用，节省的发布成本相当可观。
2.2 同vite等工具的选型对比
我也不是没用vite，但vite的定位跟webpack5有很明显的场景差异，下面这个对比可以根据团队情况自行判断。
| 维度 | webpack5 | vite |
|---|---|---|
| 冷启动速度 | 较慢，依赖持久化缓存优化 | 极快，基于原生ESM按需编译 |
| 生态插件量 | 非常丰富，历史沉淀多 | 相对较新，但增长趋势快 |
| 生产构建成熟度 | 非常成熟，Tree Shaking和分包策略稳定 | 生产构建默认基于Rollup，大项目定制深度略逊 |
| 微前端配合 | 支持Module Federation | 需借助插件，但通常与webpack容器结合 |
| 历史项目迁移 | webpack4项目平滑升级 | 大型项目迁移成本高 |
我这里强调的是偏传统前端工程化改造、需要深度定制构建细节、生态依赖Webpack能力的场景，webpack5会舒服很多。vite更适合新启动的纯前端业务、追求开发极速体验、不依赖federation等技术点的项目。两者不互斥，不同技术栈各有各的位置。
2.3 工程化思路的整体设计原则
我这次搭建工程化体系，不是简单写一份webpack.config.js就完事，而是按工程化的完整链路来设计的：规范化的目录分层、多环境配置拆分、构建配置复用、代码规范自动化、资源处理策略、开发体验优化、性能分析可视化，最后是CI/CD的配合。
在配置拆分上，我没有把所有环境逻辑全塞进一个config里，而是拆分成了webpack.base.conf.js（公共配置）、webpack.dev.conf.js（开发环境）、webpack.prod.conf.js（生产环境）、webpack.analy.conf.js（性能分析）四个文件，通过webpack-merge做合并。这样每个环境的配置职责清晰，后续在哪个环境加什么配置直接进对应文件加，不用在if (process.env.NODE_ENV)里面翻来翻去找，维护成本低很多。
你可能觉得拆分文件显得没必要的繁琐，但真实项目跑起来就知道好处——排查构建问题、临时切换环境、多人并行改配置的时候，这个拆分的价值就体现出来了。
3. 实操搭建：基于webpack5的完整工程化配置
3.1 项目初始化与目录结构规范
先创建一个新项目，我建议从项目目录这里就把规范立好，后面代码往里面填才会越填越清晰。贴一下我用的目录结构：
bash复制webpack5-engineering
├── package.json
├── babel.config.js
├── webpack
│ ├── webpack.base.conf.js
│ ├── webpack.dev.conf.js
│ └── webpack.prod.conf.js
└── src
├── api
├── assets
├── components
├── router
├── store
├── styles
├── utils
├── views
├── App.vue
└── main.js
如果你用React，把components、hooks放进去也是一样的。核心思路是：按功能而不是按文件类型划分目录，这样团队协作时，知道工具函数放在哪、接口统一在哪、页面组件在哪，不需要问人也不需要看文档。
package.json脚本我是这样定义的：
json复制{
"scripts"