Webpack 5 Phase Universe 相位宇宙是什么？新特性深度解析

Webpack 5 发布之后，前端社区流传着一个略带科幻色彩的说法——Phase Universe，中文译作相位宇宙。它并不是某个具体的配置项或插件名，而是开发者对 Webpack 5 内部一系列架构级重构的统称：从文件系统缓存到模块图构建，再到模块联邦带来的跨应用运行时共享，整个打包流程像是被切分成了多个可独立演进的“相位”。这篇文章就来拆解这些相位背后的技术细节，看看它们究竟给日常构建带来了什么变化。

一、持久化缓存：第一次让增量构建真正可用

Webpack 4 时代的缓存主要靠 cache: true 配合 memory 模式，进程一旦退出，缓存全部丢失。对于中大型项目来说，本地二次启动依然要经历完整的模块解析、编译和代码生成流程，冷启动动辄一两分钟是常态。Webpack 5 引入了基于文件系统的持久化缓存，把编译中间产物序列化到磁盘上，下次启动时直接读取缓存，跳过大部分解析和转换工作。

启用方式非常简单，在配置文件中添加如下片段即可：

module.exports = {
  cache: {
    type: 'filesystem',
    buildDependencies: {
      // 配置文件本身变化时，缓存自动失效
      config: [__filename]
    },
    cacheDirectory: path.resolve(__dirname, '.webpack_cache'),
    version: '1.0.0'
  }
};

这里有几个细节值得注意。buildDependencies 用来声明哪些文件属于构建依赖，一旦这些文件的内容或时间戳变化，缓存会整体作废，避免出现配置改了但产物还是旧的诡异问题。version 字段则适合在升级依赖、切换分支后手动提升，强制触发一次全量编译。实测下来，一个模块数超过三千的中型项目，冷启动从原来的 90 秒左右降到 15 秒以内，效果相当明显。

另一个容易被忽视的点是缓存的安全性。Webpack 5 会为每个模块计算内容哈希，只要源文件没变，即使文件被 touch 过，也不会触发重新编译。这意味着频繁切换分支时，只要两个分支的文件内容一致，缓存依然可以复用，这是 Webpack 4 时代做不到的。

二、模块联邦：跨应用的运行时共享

如果说持久化缓存解决的是构建速度问题，那 Module Federation（模块联邦）解决的就是架构层面的问题。它允许多个独立构建、独立部署的应用在运行时互相暴露和消费模块，天然适配微前端场景。过去要做微前端，通常得依赖 npm 私有包发版或者 runtime 注入脚本，迭代链路长且版本同步困难。模块联邦把共享粒度下沉到了模块级别，宿主应用可以在运行时按需加载远程应用的组件。

一个最小的宿主配置如下：

const { ModuleFederationPlugin } = require('webpack').container;

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'host',
      remotes: {
        // 运行时从远程应用加载 sharedComponents
        remoteApp: 'remoteApp@http://cdn.ipipp.com/remote/remoteEntry.js'
      },
      shared: {
        react: { singleton: true },
        'react-dom': { singleton: true }
      }
    })
  ]
};

远程应用只需要用 exposes 字段声明要暴露的模块。双方通过 shared 声明公共依赖后，Webpack 会在运行时协商版本，优先复用宿主已加载的 React 实例，避免出现页面上同时存在两份 React 导致 hooks 报错的问题。singleton: true 表示整个页面只允许一份实例存在，这是微前端场景下必须打开的开关。

需要提醒的是，模块联邦对公共依赖的版本容忍度有上限。如果宿主用 React 18、远程用 React 16，即使声明了 shared，运行时也可能出现不兼容行为。最佳实践是把共享依赖的版本范围约定在同一个大版本内，并通过 CI 校验双方 package.json 的一致性。

三、Tree Shaking 与产物优化：嵌套的无用代码也能被摇掉

Webpack 5 对 Tree Shaking 做了一次深度增强，最直观的改进是支持嵌套属性的无效导出清除。举个例子，某个工具模块导出了一个对象，对象内部有几十个方法，业务代码只用到其中一个。Webpack 4 无法分析这种情况，会把整个对象打进去；Webpack 5 借助更精细的模块图分析，可以只保留被引用的那个方法。

配合另一个新特性——顶层 await 支持和更好的 sideEffects 分析，产物体积的压缩空间进一步扩大。建议在 package.json 中如实标注 sideEffects: false（或列出有副作用的文件列表），这是让 Tree Shaking 充分工作的前提：

{
  "name": "my-utils",
  "version": "1.0.0",
  "sideEffects": false,
  "module": "dist/esm/index.js"
}

此外，Webpack 5 移除了 Node.js polyfill 的自动注入。过去浏览器端打包时，只要引用了某个依赖 Node API 的库，Webpack 4 会默默塞进一坨 polyfill，导致产物莫名膨胀。Webpack 5 改为直接报错提示，迫使开发者显式声明 fallback 或自行引入合适的 polyfill。这个变化初期会让不少升级者踩坑，但长期看对产物体积和构建确定性都是好事。

四、升级迁移建议与常见坑

升级 Webpack 5 之前，建议先用官方提供的统计工具分析现有项目的兼容性。迁移过程中最常见的三类问题：一是 Node polyfill 报错，需要按报错信息逐个安装并配置 resolve.fallback；二是部分老旧插件不兼容新版的 Hook API，需要升级插件版本或寻找替代品；三是持久化缓存放进 CI 时要注意缓存的 key 策略，避免不同分支之间互相污染缓存。

对于仍在使用 Webpack 4 的项目，如果构建时间长、产物体积大、或者正计划落地微前端，升级到 Webpack 5 的收益非常明确。反之，如果项目规模小、构建本来就在十秒以内，可以不必着急，等依赖生态完全稳定后再迁移也不迟。总体来看，这组被社区称为 Phase Universe 的架构演进，标志着 Webpack 从单纯的打包工具向长期构建基础设施的转变，值得每个前端工程师花时间理解其背后的设计思路。

Webpack 5Phase Universe模块联邦修改时间：2026-09-09 00:31:03