Webpack 5 对构建流程的改进并不是推出一个亮点特性就结束，而是把缓存、模块 ID、资源处理、代码分割等多个环节串成完整的优化闭环。升级之后，开发服务器启动速度、二次构建耗时以及线上缓存命中率都会有明显变化。这种变化来源于 Webpack 核心团队对构建体验的持续改进，而不是依赖某个单独的插件或 loader。

持久化缓存与确定性 ID 的改进

Webpack 5 之前，想要实现跨进程的构建缓存通常需要借助 hard-source-webpack-plugin 或 cache-loader 等第三方方案，配置繁琐且容易因环境差异失效。Webpack 5 直接将持久化缓存内置到核心，通过 cache.type 设置为 filesystem 就能把模块构建结果写入磁盘。二次构建时，Webpack 会优先读取缓存，跳过已经解析和编译过的模块，从而把分钟级的冷启动降到秒级。

持久化缓存的稳定性依赖于模块标识是否确定。Webpack 4 中 module.id 和 chunk.id 默认是自增数字，新增或删除模块后，后面的 ID 都会发生变化，导致 vendor 和业务代码的 chunk hash 全部改变，长期缓存难以命中。Webpack 5 新增了 deterministic 选项，分别通过 optimization.moduleIds 和 optimization.chunkIds 指定。该模式会根据模块的相对路径生成稳定的短 ID，内容不变 ID 就不变，非常适合生产环境的长期缓存。

下面是一个启用持久化缓存和确定性 ID 的典型配置：

module.exports = {
  cache: {
    type: 'filesystem',
    buildDependencies: {
      config: [__filename]
    }
  },
  optimization: {
    moduleIds: 'deterministic',
    chunkIds: 'deterministic',
    runtimeChunk: 'single'
  }
};

这里把 config 文件加入 buildDependencies，是为了让配置文件变化时缓存自动失效，避免旧缓存导致构建结果不一致。runtimeChunk 设置为 single 则把运行时代码单独拆分，更有利于长期缓存。

不过，持久化缓存并非没有成本。缓存目录会占用额外的磁盘空间，CI 环境需要配合缓存恢复策略才能发挥最大效果。同时，某些依赖二进制插件或使用动态路径的模块可能因序列化问题导致缓存失效。出现异常时，可以尝试删除 node_modules/.cache 目录后重新构建。

资源模块与 Asset Modules 的优化

Webpack 4 处理图片、字体、音频等静态资源时，通常需要配置 url-loader、file-loader 或 raw-loader，每种资源的规则和配置项分散，维护起来容易出错。Webpack 5 引入的资源模块（Asset Modules）把这些能力统一为四种类型：asset/resource、asset/inline、asset/source 和 asset。其中 asset 会根据资源大小自动在 resource 和 inline 之间切换，减少了对额外 loader 的依赖。

这种改进对构建性能的影响主要体现在两个方面：一方面，内置实现避免了多个 loader 之间的文件读写和转换开销；另一方面，统一的模块类型让模块树更清晰，Tree Shaking 和代码分割能够更准确地判断资源依赖。例如，使用 asset 类型处理图片时，小于 8KB 的文件会被内联为 base64，减少 HTTP 请求，大于阈值的文件则被单独输出为静态文件并携带内容 hash。

下面是一个典型的资源模块配置：

module.exports = {
  module: {
    rules: [
      {
        test: /\.png$/,
        type: 'asset',
        parser: {
          dataUrlCondition: {
            maxSize: 8 * 1024
          }
        }
      },
      {
        test: /\.svg$/,
        type: 'asset/source'
      }
    ]
  },
  output: {
    assetModuleFilename: 'assets/[name].[contenthash][ext]'
  }
};

这种统一化处理也让升级路径更加平滑。原来使用 url-loader 的项目可以直接删除对应 loader 依赖，把 type 设置为 asset，配合 dataUrlCondition 就能保留原有的大小限制行为。需要注意的是，资源模块输出的文件默认不会经过公共路径拼接，当项目部署到 CDN 时，要确认 output.publicPath 是否正确配置。

模块联邦与代码分割的持续改进

Webpack 5 的模块联邦（Module Federation）是持续改进思路中比较有代表性的特性。它允许多个独立构建的应用在运行时共享模块，避免重复打包公共依赖，也能实现微前端场景下的按需加载。与传统的 externals 或 DLL 方案不同，模块联邦通过 ModuleFederationPlugin 暴露和消费模块，共享范围可以是组件、工具函数，甚至是完整的应用入口。

从构建性能角度看，模块联邦减少了跨应用重复编译公共库的次数。每个应用独立构建，但公共依赖通过共享配置在运行时动态复用。这样，当某个公共库升级时，不需要所有下游应用重新构建，只需要更新提供方的部署即可。这种模式非常适合多团队维护的大型项目。

下面是一个简单的模块联邦配置示例：

const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'host',
      remotes: {
        remoteApp: 'remoteApp@http://localhost:3001/remoteEntry.js'
      },
      shared: {
        react: { singleton: true, eager: false }
      }
    })
  ]
};

这里 host 作为宿主应用，通过 remotes 指向远程应用的入口文件。shared 配置声明 react 为单例共享依赖，避免两个应用各自加载不同版本的 React。eager 为 false 表示按需加载，进一步提升首屏性能。

在代码分割方面，Webpack 5 改进了 splitChunks 的默认行为，尤其是对异步 chunk 的处理。minSize 和 maxAsyncRequests 等默认值更贴合实际场景，减少了过度拆分带来的请求数量膨胀。配合 runtimeChunk 和 deterministic ID，异步加载的 chunk 命名和缓存也变得更加稳定。

Tree Shaking 与产物质量优化

Tree Shaking 是前端构建中减少未使用代码的关键技术。Webpack 5 对 Tree Shaking 的持续改进主要体现在作用域分析和副作用标记上。通过更精确的 import/export 分析，Webpack 能够在打包阶段删除未被引用的导出，而不是简单地把整个模块都保留下来。这对第三方库的按需加载尤其重要。

为了让 Tree Shaking 发挥最大效果，package.json 中的 sideEffects 字段必须准确声明。如果某个模块没有副作用，应该设置为 false 或指定文件数组。Webpack 5 也会更严格地遵循该字段，避免因为保守策略保留不必要的代码。例如，一个工具库的 package.json 可以这样写：

{
  "name": "utils-lib",
  "sideEffects": [
    "./src/polyfill.js",
    "*.css"
  ]
}

该配置告诉 Webpack 除了 polyfill.js 和 CSS 文件外，其他模块都是纯函数或类导出，可以安全地删除未使用的部分。如果不想维护 sideEffects，可以使用 mode 为 production 时默认开启的 usedExports 分析，但准确声明 sideEffects 仍然是最可靠的优化手段。

此外，Webpack 5 对嵌套的 export 和 reexport 也做了优化。例如，一个模块通过 export * from './utils' 重新导出多个函数，旧版本可能无法判断哪些函数被外部引用，导致整个 utils 文件被打包。Webpack 5 会生成更细粒度的导出映射，只保留实际被引用的部分。这对使用 barrel 文件的组件库来说，能显著降低产物体积。

如何把这些持续改进落地到现有项目

升级到 Webpack 5 后，建议从缓存、模块 ID 和资源模块三个方向逐步调整配置。第一步是启用 filesystem 持久化缓存，并设置 deterministic 的 moduleIds 和 chunkIds。这一步配置量很小，但对二次构建和长期缓存收益最大。第二步是检查项目中是否还在使用 url-loader、file-loader 等旧方案，将它们替换为资源模块类型。第三步是评估模块联邦是否适合当前架构，如果项目存在多个独立应用且共享公共依赖，可以逐步引入 ModuleFederationPlugin。

在落地过程中，要注意构建产物的一致性。开启持久化缓存后，CI 环境需要把缓存目录作为任务产物保留。可以使用如下配置让缓存目录更容易管理：

module.exports = {
  cache: {
    type: 'filesystem',
    cacheDirectory: 'node_modules/.cache/webpack',
    compression: 'gzip',
    store: 'pack'
  }
};

compression 设置为 gzip 可以减少缓存文件占用的磁盘空间，store 设置为 pack 则让缓存以单个文件形式存储，方便 CI 归档和恢复。这样在 Jenkins 或 GitLab CI 中，只需在任务结束后上传缓存文件，下次构建前下载解压即可。

最后要强调的是，持续改进不意味着一次升级就能解决所有问题。Webpack 5 的这些特性需要结合业务场景和基础设施逐步验证。建议先在开发环境启用持久化缓存，观察缓存命中率和构建时间的变化，再推广到生产构建。同时，关注 Webpack 官方文档和版本更新日志，持续跟进新的优化项，避免配置停留在旧模式上。