JS `Webpack` `Persistent Caching` `Algorithm` 与 `Cache Group` 优化

各位观众老爷们，大家好！今天咱们来聊聊 Webpack 的持久化缓存，以及如何通过算法和缓存组优化它。保证让你的构建速度飞起来，省下的时间多摸几条鱼！

开场白：Webpack 缓存的重要性，以及为什么我们需要优化它

Webpack 作为前端工程化的基石，打包速度一直是大家心中的痛。特别是项目越来越大，依赖越来越多的时候，每次改动一行代码，都要等半天才能看到效果，简直让人怀疑人生。

这个时候，Webpack 的缓存就显得尤为重要了。它能把那些没变过的模块缓存起来，下次构建的时候直接拿来用，大大减少了构建时间。

但是，Webpack 默认的缓存策略有时候并不够智能，可能会出现缓存失效，或者缓存粒度太粗，导致一些不必要的重复构建。所以，我们需要深入了解 Webpack 的缓存机制，并掌握一些优化技巧，让我们的构建速度更快更稳。

第一部分：Webpack 持久化缓存机制详解

Webpack 的持久化缓存，简单来说，就是把构建结果存储到磁盘上，下次构建的时候直接从磁盘读取，而不是重新构建。这样可以避免重复劳动，提高构建速度。

Webpack 提供了多种缓存类型，我们可以根据自己的需求选择合适的类型。

• memory (默认): 缓存保存在内存中。速度最快，但是重启后缓存会丢失。适用于开发环境，快速迭代。

• filesystem: 缓存保存在文件系统中。速度比内存慢，但是重启后缓存不会丢失。适用于生产环境，或者需要长期缓存的场景。

• node-filesystem: 与 filesystem 类似，但针对 Node.js 环境做了优化。

• idle: 在空闲时间执行缓存清理和优化。

配置持久化缓存

在 webpack.config.js 文件中，我们可以通过 cache 选项来配置持久化缓存。

module.exports = {
  // ...
  cache: {
    type: 'filesystem', // 使用文件系统缓存
    cacheDirectory: '.webpack_cache', // 缓存目录
    // name: 'my-project-cache', // 缓存名称 (可选)
    store: 'pack', // 'pack' | 'idle'，缓存数据存储方式 (可选)
    buildDependencies: { // 配置构建依赖
      config: [__filename], // 当构建配置文件修改时，缓存失效
      // 也可以添加其他依赖文件，例如：
      // defaultWebpack: ['webpack/lib/'],
    },
  },
  // ...
};

缓存失效策略

Webpack 的缓存失效策略非常重要，它决定了什么时候应该使用缓存，什么时候应该重新构建。

Webpack 会根据以下几个因素来判断缓存是否有效：

1. 模块内容哈希值 (Content Hash): 这是最核心的判断依据。如果模块的内容发生了变化，那么它的哈希值也会发生变化，Webpack 就会认为缓存失效，需要重新构建。

2. 模块依赖关系 (Dependency Graph): 如果模块的依赖关系发生了变化，例如新增或删除了依赖模块，那么Webpack 也会认为缓存失效。

3. 构建配置 (Webpack Configuration): 如果 Webpack 的配置发生了变化，例如修改了 loader 的配置，或者修改了插件的配置，那么 Webpack 也会认为缓存失效。

4. 版本信息 (Version Information): Webpack 会记录一些版本信息，例如 Webpack 的版本，Node.js 的版本，以及 loader 和插件的版本。如果这些版本信息发生了变化，那么 Webpack 也会认为缓存失效。

5. 时间戳 (Timestamp): Webpack 会记录模块的修改时间戳。如果模块的修改时间戳晚于缓存的时间戳，那么 Webpack 也会认为缓存失效。

代码示例：配置缓存失效依赖

module.exports = {
  // ...
  cache: {
    type: 'filesystem',
    buildDependencies: {
      config: [__filename, 'babel.config.js'], // babel配置文件修改也导致缓存失效
      // 如果使用了 postcss, 也可以添加 postcss.config.js
      // defaultWebpack: ['webpack/lib/'],
    },
  },
  // ...
};

第二部分：Webpack 缓存优化算法

Webpack 的缓存优化算法，主要是为了提高缓存的命中率，减少缓存的失效，从而提高构建速度。

1. moduleIds: 'deterministic'

默认情况下，Webpack 会使用数字 ID 来标识模块。但是，这种数字 ID 会随着模块的增删而发生变化，导致缓存失效。

moduleIds: 'deterministic' 可以让 Webpack 使用模块的路径生成一个唯一的 ID，这个 ID 不会随着模块的增删而发生变化，从而提高缓存的命中率。

代码示例：配置 moduleIds

module.exports = {
  // ...
  optimization: {
    moduleIds: 'deterministic', // 使用确定的模块 ID
  },
  // ...
};

2. chunkIds: 'deterministic'

与 moduleIds 类似，chunkIds 也是用来标识代码块的。默认情况下，Webpack 也会使用数字 ID 来标识代码块。

chunkIds: 'deterministic' 可以让 Webpack 使用代码块的内容生成一个唯一的 ID，这个 ID 不会随着代码块的增删而发生变化，从而提高缓存的命中率。

代码示例：配置 chunkIds

module.exports = {
  // ...
  optimization: {
    chunkIds: 'deterministic', // 使用确定的代码块 ID
  },
  // ...
};

3. namedChunks: true / nameAllModules: true (开发环境)

在开发环境中，为了方便调试，我们可以使用 namedChunks: true 和 nameAllModules: true。

namedChunks: true 可以让 Webpack 使用代码块的名称来标识代码块，而不是使用数字 ID。

nameAllModules: true 可以让 Webpack 使用模块的路径来标识模块，而不是使用数字 ID。

这样，在调试的时候，我们可以更方便地找到对应的代码块和模块。但是，这两个选项会增加构建时间，所以在生产环境中不建议使用。

4. splitChunks 的智能配置

splitChunks 是 Webpack 中用于代码分割的插件。它可以把一些公共的代码分割成单独的代码块，从而减少代码的重复，提高缓存的命中率。

splitChunks 的配置非常灵活，我们可以根据自己的需求进行配置。

常见的配置项包括：

• chunks: 指定要分割的代码块类型，例如 all、async、initial。
• minSize: 指定代码块的最小大小，只有大于这个大小的代码块才会被分割。
• maxSize: 指定代码块的最大大小，如果代码块大于这个大小，会被进一步分割。
• minChunks: 指定代码块被引用的最小次数，只有被引用次数大于这个次数的代码块才会被分割。
• maxAsyncRequests: 指定异步代码块的最大请求数。
• maxInitialRequests: 指定初始代码块的最大请求数。
• automaticNameDelimiter: 指定代码块名称的分隔符。
• name: 指定代码块的名称。
• cacheGroups: 指定缓存组，可以根据不同的规则把代码块分割到不同的缓存组中。

代码示例：配置 splitChunks

module.exports = {
  // ...
  optimization: {
    splitChunks: {
      chunks: 'all', // 分割所有代码块
      cacheGroups: {
        vendors: { // 将所有来自 node_modules 的模块分割到 vendors 代码块中
          test: /[\/]node_modules[\/]/,
          priority: -10,
          name: 'vendors',
        },
        default: { // 将被多次引用的模块分割到 default 代码块中
          minChunks: 2,
          priority: -20,
          reuseExistingChunk: true, // 如果模块已经被分割过，则直接复用
          name: 'default'
        },
      },
    },
  },
  // ...
};

第三部分：缓存组 (Cache Groups) 的高级应用

cacheGroups 是 splitChunks 的一个重要配置项，它可以让我们更灵活地控制代码分割。我们可以根据不同的规则把代码块分割到不同的缓存组中，从而提高缓存的命中率。

1. 根据模块类型分割

我们可以根据模块的类型把代码块分割到不同的缓存组中，例如把 JavaScript 模块分割到一个缓存组中，把 CSS 模块分割到另一个缓存组中。

代码示例：根据模块类型分割

module.exports = {
  // ...
  optimization: {
    splitChunks: {
      cacheGroups: {
        javascript: { // 将所有 JavaScript 模块分割到 javascript 代码块中
          test: /.js$/,
          priority: 10,
          name: 'javascript',
        },
        css: { // 将所有 CSS 模块分割到 css 代码块中
          test: /.css$/,
          priority: 20,
          name: 'css',
        },
      },
    },
  },
  // ...
};

2. 根据模块大小分割

我们可以根据模块的大小把代码块分割到不同的缓存组中，例如把大于 100KB 的模块分割到一个缓存组中，把小于 100KB 的模块分割到另一个缓存组中。

代码示例：根据模块大小分割

module.exports = {
  // ...
  optimization: {
    splitChunks: {
      cacheGroups: {
        large: { // 将所有大于 100KB 的模块分割到 large 代码块中
          minSize: 100 * 1024, // 100KB
          priority: 10,
          name: 'large',
        },
        small: { // 将所有小于 100KB 的模块分割到 small 代码块中
          maxSize: 100 * 1024, // 100KB
          priority: 20,
          name: 'small',
        },
      },
    },
  },
  // ...
};

3. 根据模块来源分割

我们可以根据模块的来源把代码块分割到不同的缓存组中，例如把来自 node_modules 的模块分割到一个缓存组中，把来自项目的模块分割到另一个缓存组中。

代码示例：根据模块来源分割

module.exports = {
  // ...
  optimization: {
    splitChunks: {
      cacheGroups: {
        vendors: { // 将所有来自 node_modules 的模块分割到 vendors 代码块中
          test: /[\/]node_modules[\/]/,
          priority: 10,
          name: 'vendors',
        },
        app: { // 将所有来自项目的模块分割到 app 代码块中
          test: /[\/]src[\/]/,
          priority: 20,
          name: 'app',
        },
      },
    },
  },
  // ...
};

4. 自定义匹配规则

cacheGroups 的 test 属性可以接受一个正则表达式，我们可以使用正则表达式来定义更复杂的匹配规则。

例如，我们可以把所有以 .vue 结尾的模块分割到一个缓存组中：

module.exports = {
  // ...
  optimization: {
    splitChunks: {
      cacheGroups: {
        vue: { // 将所有以 .vue 结尾的模块分割到 vue 代码块中
          test: /.vue$/,
          priority: 10,
          name: 'vue',
        },
      },
    },
  },
  // ...
};

表格总结：常用 splitChunks 配置项

配置项	类型	描述
chunks	string	指定要分割的代码块类型。可选值：all (所有代码块), async (异步代码块), initial (初始代码块)。
minSize	number	指定代码块的最小大小，只有大于这个大小的代码块才会被分割。
maxSize	number	指定代码块的最大大小，如果代码块大于这个大小，会被进一步分割。
minChunks	number	指定代码块被引用的最小次数，只有被引用次数大于这个次数的代码块才会被分割。
maxAsyncRequests	number	指定异步代码块的最大请求数。
maxInitialRequests	number	指定初始代码块的最大请求数。
automaticNameDelimiter	string	指定代码块名称的分隔符。
name	string	指定代码块的名称。
cacheGroups	object	指定缓存组，可以根据不同的规则把代码块分割到不同的缓存组中。每个缓存组都是一个对象，包含以下属性：test (匹配规则), priority (优先级), reuseExistingChunk (是否复用已存在的代码块), name (代码块名称), chunks (要分割的代码块类型), minSize (最小大小), maxSize (最大大小), minChunks (最小引用次数), maxAsyncRequests (最大异步请求数), maxInitialRequests (最大初始请求数)。

第四部分：其他优化技巧

除了上面介绍的缓存优化算法和缓存组配置，还有一些其他的优化技巧可以帮助我们提高 Webpack 的构建速度。

1. 使用 ES Modules

ES Modules (ECMAScript Modules) 是 JavaScript 的官方模块标准。与 CommonJS 相比，ES Modules 具有静态分析的特性，Webpack 可以更准确地分析模块之间的依赖关系，从而更好地进行代码分割和缓存优化。

2. 使用 Tree Shaking

Tree Shaking 是一种移除 JavaScript 代码中未使用的代码的技术。它可以减少代码的体积，提高加载速度。

Webpack 默认支持 Tree Shaking，但是需要满足一些条件才能生效。例如，我们需要使用 ES Modules，并且不能使用副作用代码。

3. 使用 HappyPack / Thread-loader

HappyPack 和 Thread-loader 都是用于多线程构建的工具。它们可以把 Webpack 的构建任务分配到多个线程中并行执行，从而提高构建速度。

4. 优化 Loader 的配置

Loader 是 Webpack 中用于处理各种类型文件的工具。Loader 的配置会直接影响构建速度。

我们可以通过以下方式来优化 Loader 的配置：

• 减少 Loader 的数量：只使用必要的 Loader。
• 优化 Loader 的配置：例如，对于 babel-loader，可以使用 cacheDirectory 选项来缓存编译结果。
• 使用 include 和 exclude 选项：只对需要处理的文件使用 Loader。

5. 使用 DLLPlugin / DllReferencePlugin

DLLPlugin 和 DllReferencePlugin 是一对插件，可以把一些不经常变化的模块（例如第三方库）打包成一个 DLL 文件，然后在构建的时候直接引用这个 DLL 文件，而不是重新构建。这样可以大大减少构建时间。

6. 升级 Webpack 版本

Webpack 的每个版本都会进行一些优化，升级到最新的 Webpack 版本通常可以提高构建速度。

总结：持久化缓存优化是一个持续的过程

Webpack 的持久化缓存优化是一个持续的过程，我们需要根据项目的实际情况不断调整配置，才能达到最佳的构建速度。

总而言之，理解缓存机制，巧妙运用各种算法和配置，才能让我们的 Webpack 构建速度起飞！希望今天的分享对大家有所帮助，祝大家工作顺利，早日实现财务自由！ 咱们下期再见！