Webpack 5 发布已经有一段时间，但不少人对它的印象还停留在版本号的变化上。实际上，这个版本带来的改进远比想象中彻底，以至于社区里有人用 Polish Universe 来形容它，意思是整个构建体系像被放进一台抛光机里打磨过一遍。这不是一个官方代号，却准确传达了 Webpack 5 的核心思路：不追求颠覆式重写，而是针对构建速度、配置复杂度、资源处理和模块协作这些长期被诟病的环节做精细化优化。接下来我们围绕几个关键特性展开，看看它们如何解决实际开发中的麻烦。
持久化缓存：二次构建的质变
Webpack 4 的缓存能力一直比较薄弱。虽然可以通过 cache-loader 或者 babel-loader 的缓存目录来缓解，但这些方案要么只针对单个 loader，要么需要额外维护缓存文件，整体效果有限。Webpack 5 直接在核心层引入了文件系统级别的持久化缓存，默认情况下开启 memory 缓存，而配置 cache.type 为 filesystem 后，模块和 chunk 的编译结果会被序列化到磁盘上。下次启动构建时，Webpack 会先检查缓存是否有效，如果源码和依赖没有变化，就直接复用上次的结果，跳过耗时的编译和压缩阶段。
这个特性对大型项目的收益尤其明显。以一个包含上千个模块的中型单页应用为例，首次构建可能需要 40 秒到 60 秒，开启持久化缓存后，二次构建往往能压缩到 3 秒以内，因为大部分模块根本没有发生变化。原理上，Webpack 会将每个模块的依赖图、转换后的代码、source map 等信息存储为二进制文件，并通过内容哈希来判断缓存是否命中。需要提醒的是，这种缓存不适合放在持续集成环境中长期复用，因为 node_modules 的变化可能带来缓存失效问题，但在本地开发场景下，它几乎是无脑开启的优化项。
// webpack.config.js
module.exports = {
cache: {
type: 'filesystem',
buildDependencies: {
config: [__filename]
}
}
};
配置项 buildDependencies 用来声明哪些文件的变更会导致缓存失效，这里把配置文件本身加进去，避免修改配置后仍然使用旧缓存。如果发现缓存行为异常，可以删除 node_modules/.cache 目录来强制重建。
资源模块：原生能力替代 loader 组合
在 Webpack 4 时代，处理图片、字体、SVG 等静态资源需要组合使用 file-loader、url-loader 和 raw-loader。开发者不仅要记住每个 loader 的配置差异，还得处理大小限制、输出路径、公共路径等细节。Webpack 5 新增了 asset modules 类型，从底层支持四种资源处理方式：asset/resource 对应 file-loader，asset/inline 对应 url-loader 的内联模式，asset/source 对应 raw-loader，asset 则提供自动选择内联或单独文件的通用模式。
使用方式非常直观，只需要在 module.rules 中把 type 设置为对应的值，不再需要安装额外的 loader。例如下面的配置会将小于 8kb 的图片转为 base64 内联，超过限制的图片则输出到 dist/images 目录。这种原生实现不仅减少了依赖数量，还提升了处理性能，因为 Webpack 不再需要通过 loader 链来转换文件内容。迁移项目时，只需把原来的 file-loader 规则替换成 type: 'asset/resource'，再把 url-loader 的 limit 逻辑交给 asset 的 parser.dataUrlCondition.maxSize 即可。
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /\.(png|jpg|gif|svg)$/,
type: 'asset',
parser: {
dataUrlCondition: {
maxSize: 8 * 1024
}
},
generator: {
filename: 'images/[name].[hash:8][ext]'
}
}
]
}
};
还有一个容易忽略的细节：Webpack 5 的资源模块对 JSON 文件也有了更好的支持。虽然 JSON 模块在 Webpack 4 中也能用，但 Webpack 5 允许更细粒度的解析控制，并且不再需要 json-loader。对于需要动态加载 JSON 的场景，可以使用 import() 配合 type: 'json' 来实现按需解析。
模块联邦：微前端的原生级方案
微前端是近几年的热门话题，但以往实现微前端往往需要借助 single-spa、qiankun 等框架，或者通过 iframe、Web Components 等方式拼接。Webpack 5 提供的 Module Federation 插件，则是在构建工具层面直接支持了跨应用的模块共享。简单来说，它允许一个应用在运行时从另一个应用的构建产物中加载模块，而不需要把这些模块打包进自己的 bundle 里。
这个能力的核心是 exposes 和 remotes 两个配置。exposes 表示当前应用对外暴露哪些模块，remotes 表示当前应用需要消费哪些远程模块。下面是一个简单的示例：主机应用 remoteApp 暴露了一个 Button 组件，主应用 hostApp 通过 remotes 引入它。运行时，主应用会向远程地址请求 remoteEntry.js，然后根据模块映射找到对应的组件代码。与普通的动态 import 不同，模块联邦支持依赖共享、版本协商和单例控制，避免了重复加载同一依赖的问题。
// remoteApp/webpack.config.js
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'remoteApp',
filename: 'remoteEntry.js',
exposes: {
'./Button': './src/components/Button'
}
})
]
};
// hostApp/webpack.config.js
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'hostApp',
remotes: {
remoteApp: 'remoteApp@http://localhost:3001/remoteEntry.js'
}
})
]
};
模块联邦的落地需要处理好部署和版本管理。官方推荐在生产环境中为每个远程应用配置独立的 publicPath，并利用 contenthash 来保证缓存更新。另外，共享依赖的配置要谨慎，尤其是 React 这类库，如果多个应用各自打包了不同版本的 React，可能会导致 hooks 调用出错。通过 shared 字段把 react、react-dom 声明为 singleton，可以强制所有应用使用同一个实例。
树摇优化与代码分割的深层改进
Tree shaking 是前端性能优化的常规手段，但 Webpack 4 对 ES module 的分析存在一些边界问题，比如嵌套的 export * 语句、类静态属性等场景会被误判为有副作用而保留。Webpack 5 重构了内部模块图的数据结构，改为基于引用计数的 ModuleGraph，同时加强了与 terser 等压缩工具的配合。这意味着同样的代码在 Webpack 5 中可能摇掉更多无用分支，尤其是那些通过 re-export 引入的模块。
配合 sideEffects 配置，开发者可以精确标记哪些文件是无副作用的，从而让压缩工具放心删除。例如在 package.json 中设置 sideEffects: false，Webpack 就会假设所有模块都是纯净的，除非某个文件确实有副作用需要单独列出。不过需要注意，样式文件、polyfill 等通常带有副作用，把它们排除在 sideEffects 之外才能避免被误删。另一个变化是 Webpack 5 对动态导入的默认行为和代码分割策略做了调整，配合 optimization.splitChunks 可以更细致地控制公共模块的提取，减少重复代码。
从包体积的角度看，Webpack 5 的打包结果往往比 Webpack 4 小几个百分点，但具体收益取决于项目结构和代码写法。如果项目大量使用 CommonJS 模块，树摇效果会打折扣，因为 CommonJS 的动态特性让静态分析很难发挥。这也是为什么 Webpack 5 鼓励使用 ESM 写库和业务代码，同时提供了 experiments.outputModule 选项，允许输出真正的 ES module 格式，为未来浏览器原生加载和更好的长期缓存打下基础。
Webpack 5Polish Universe构建优化修改时间：2026-10-04 14:09:45