避免重复打包：SplitChunksPlugin的配置与优化策略

1. Webpack中的重复打包问题

在前端项目开发过程中，随着项目规模的不断扩大，代码量和依赖模块数量也会急剧增加。Webpack作为主流的前端构建工具，在打包过程中如果处理不当，很容易出现重复打包的问题。

例如，假设我们有两个JavaScript模块moduleA和moduleB，它们都依赖于同一个第三方库lodash。在不做任何优化的情况下，Webpack会在打包moduleA和moduleB时，分别将lodash库的代码包含进去，这就导致了lodash代码在最终的打包文件中重复出现。这种重复打包不仅会增加打包文件的体积，延长加载时间，还会降低应用程序的性能。

1.1 重复打包带来的性能影响

• 增加文件体积：重复的代码会直接导致打包后的文件体积增大。例如，一个原本100KB的打包文件，由于重复打包某个20KB的库，文件体积可能会增加到120KB甚至更多。这会使得用户在加载页面时需要下载更多的数据，增加了网络传输的负担，特别是在网络环境较差的情况下，页面加载时间会明显变长。
• 降低加载速度：浏览器在解析和执行JavaScript代码时，需要处理更大体积的文件。这不仅增加了文件的下载时间，还会消耗更多的内存和CPU资源来解析和执行这些重复的代码。比如，在一个移动设备上，加载一个200KB的JavaScript文件可能需要1 - 2秒，而加载一个因为重复打包而达到300KB的文件，可能就需要2 - 3秒甚至更长时间，严重影响用户体验。
• 影响缓存策略：浏览器通常会对加载过的文件进行缓存，以提高后续访问的速度。然而，当打包文件中存在重复代码时，如果这些重复代码所在的文件版本发生变化，整个打包文件的缓存就会失效。例如，lodash库更新了版本，由于它在多个地方重复打包，所有包含lodash的打包文件都需要重新下载，而不能利用之前的缓存，降低了缓存的命中率。

2. SplitChunksPlugin简介

SplitChunksPlugin是Webpack中用于分割代码块的插件，它可以有效地解决重复打包的问题。通过合理配置该插件，我们可以将公共的依赖模块提取出来，单独打包成一个或多个文件，避免在多个入口chunk中重复打包相同的模块。

2.1 SplitChunksPlugin的基本原理

SplitChunksPlugin会分析所有入口chunk及其依赖关系，根据配置的规则，将满足条件的公共模块提取出来，生成新的chunk。例如，对于前面提到的moduleA和moduleB都依赖lodash的情况，SplitChunksPlugin可以将lodash提取出来，单独打包成一个文件。在页面加载时，浏览器只需要下载一次这个公共模块文件，然后moduleA和moduleB都可以复用该模块，从而减少了重复代码和文件体积。

2.2 SplitChunksPlugin在Webpack中的地位

在Webpack的构建流程中，SplitChunksPlugin位于代码分割阶段。Webpack首先会根据入口文件，构建出依赖图，将所有依赖的模块都收集起来。然后，在打包阶段，SplitChunksPlugin会按照配置对这些模块进行分析和分割，将公共模块提取出来。它是Webpack实现代码优化的重要组成部分，对于提高前端应用的性能起着关键作用。

3. SplitChunksPlugin的基础配置

3.1 splitChunks.chunks

splitChunks.chunks配置项用于指定哪些chunk需要进行代码分割。它有三个取值：all、async和initial。

• async：这是默认值，表示只对异步加载的chunk（例如通过import()动态导入的模块）进行代码分割。例如，假设我们有如下异步导入模块的代码：

// 在某个模块中
import('./asyncModule').then((module) => {
    // 使用异步导入的模块
});

如果配置splitChunks.chunks: 'async'，Webpack会对asyncModule及其依赖进行分析，将公共模块提取出来。

• initial：表示只对初始加载的chunk（即通过import直接导入的模块）进行代码分割。例如，在项目的入口文件index.js中：

import React from'react';
import ReactDOM from'react - dom';
// 这里React和ReactDOM是初始加载的模块

配置splitChunks.chunks: 'initial'，Webpack会对这些初始加载模块及其依赖进行分析和分割。

• all：表示对所有的chunk（包括异步和初始加载的chunk）都进行代码分割。这种配置适用于项目中既有大量异步加载模块，又有重要公共模块需要提取的情况。

3.2 splitChunks.minSize

splitChunks.minSize配置项用于指定分割出来的chunk的最小大小（以字节为单位）。默认值是30000（即30KB）。只有当提取出来的公共模块大小超过这个值时，才会将其分割成单独的chunk。例如，如果设置splitChunks.minSize: 10000，那么当公共模块大小达到或超过10KB时，Webpack就会将其提取出来。这个配置可以避免生成过多过小的chunk，因为过小的chunk会增加HTTP请求的数量，反而可能降低性能。

3.3 splitChunks.minChunks

splitChunks.minChunks配置项用于指定模块被提取出来的最小引用次数。默认值是1，表示只要有一个chunk引用了该模块，就有可能将其提取出来。如果设置为2，那么只有当至少有两个chunk引用了同一个模块时，该模块才会被提取出来。例如，假设项目中有三个模块moduleA、moduleB和moduleC，moduleA和moduleB都引用了commonModule，而moduleC没有引用。如果splitChunks.minChunks设置为2，commonModule就会被提取出来；如果设置为3，由于没有三个模块同时引用commonModule，它就不会被提取。

3.4 splitChunks.name

splitChunks.name配置项用于指定分割出来的chunk的名称。可以是一个字符串，也可以是一个函数。例如，如果设置splitChunks.name: 'commons'，那么提取出来的公共模块就会被命名为commons.js。如果使用函数，可以根据不同的条件动态生成名称，如下：

splitChunks: {
    name: function (module, chunks, cacheGroupKey) {
        const allChunksNames = chunks.map((chunk) => chunk.name).join('~');
        return `commons - ${cacheGroupKey}-${allChunksNames}`;
    }
}

这样可以根据chunk的名称和缓存组的键生成更具描述性的名称。

4. SplitChunksPlugin的高级配置 - 缓存组（Cache Groups）

4.1 缓存组的概念

缓存组是SplitChunksPlugin中一个非常强大的功能，它允许我们更细粒度地控制代码分割。通过定义不同的缓存组，我们可以将不同类型的模块分别提取到不同的chunk中。例如，可以将所有的第三方库提取到一个chunk中，将项目内部的公共模块提取到另一个chunk中。

4.2 配置缓存组

缓存组通过splitChunks.cacheGroups进行配置。每个缓存组都有自己的配置选项，例如test、priority、reuseExistingChunk等。

• test：test配置项用于指定匹配规则，只有符合该规则的模块才会被放入这个缓存组。它可以是一个正则表达式、一个函数或者一个字符串。例如，要将所有来自node_modules的模块提取到一个缓存组中，可以这样配置：

splitChunks: {
    cacheGroups: {
        vendor: {
            test: /[\\/]node_modules[\\/]/,
            name:'vendors',
            chunks: 'all'
        }
    }
}

这里test使用正则表达式匹配node_modules目录下的模块，name指定提取出来的chunk名称为vendors.js，chunks: 'all'表示对所有chunk进行处理。

• priority：priority配置项用于指定缓存组的优先级。当一个模块同时符合多个缓存组的条件时，会优先被放入优先级高的缓存组。优先级的值越大，优先级越高。例如，有两个缓存组groupA和groupB，groupA的priority为10，groupB的priority为5，那么符合条件的模块会优先被放入groupA。

splitChunks: {
    cacheGroups: {
        groupA: {
            priority: 10,
            // 其他配置
        },
        groupB: {
            priority: 5,
            // 其他配置
        }
    }
}

• reuseExistingChunk：reuseExistingChunk配置项是一个布尔值，默认值为false。当设置为true时，如果当前要提取的模块已经存在于某个已有的chunk中，Webpack不会重新创建一个新的chunk，而是复用已有的chunk。这可以进一步减少打包文件的数量和体积。例如，假设已经有一个commons.js文件包含了一些公共模块，现在又有一个新的模块符合提取条件，并且这个模块的代码已经在commons.js中存在，设置reuseExistingChunk: true后，Webpack就不会再创建一个新的chunk来包含这个模块。

5. 结合实际项目的优化策略

5.1 多页应用（MPA）中的优化

在多页应用中，不同页面可能会有一些公共的依赖，如第三方库（如jquery、bootstrap等）和项目内部的公共组件。通过合理配置SplitChunksPlugin，可以将这些公共依赖提取出来，避免在每个页面的打包文件中重复出现。

• 配置示例：假设我们有一个多页应用，有page1、page2和page3三个页面入口，它们都依赖jquery和项目内部的commonUtils模块。Webpack配置如下：

const path = require('path');

module.exports = {
    entry: {
        page1: './src/page1.js',
        page2: './src/page2.js',
        page3: './src/page3.js'
    },
    output: {
        path: path.resolve(__dirname, 'dist'),
        filename: '[name].js'
    },
    optimization: {
        splitChunks: {
            cacheGroups: {
                vendor: {
                    test: /[\\/]node_modules[\\/]/,
                    name:'vendors',
                    chunks: 'all'
                },
                commons: {
                    name: 'commons',
                    chunks: 'initial',
                    minChunks: 2
                }
            }
        }
    }
};

这里vendor缓存组将所有来自node_modules的模块提取到vendors.js文件中，commons缓存组将至少被两个初始chunk引用的模块提取到commons.js文件中。这样，在page1.js、page2.js和page3.js的打包文件中，就不会重复包含jquery和commonUtils的代码，从而减小了文件体积，提高了加载速度。

5.2 单页应用（SPA）中的优化

在单页应用中，虽然只有一个入口文件，但随着应用功能的增加，代码会变得越来越复杂，依赖也会越来越多。同样可以利用SplitChunksPlugin来优化打包。

• 动态导入模块的优化：对于单页应用中通过import()动态导入的模块，可以利用splitChunks.chunks: 'async'配置项进行优化。例如，在一个React单页应用中，有一些路由组件是通过动态导入的方式加载的：

import React, { lazy, Suspense } from'react';
const Home = lazy(() => import('./components/Home'));
const About = lazy(() => import('./components/About'));

function App() {
    return (
        <Suspense fallback={<div>Loading...</div>}>
            <Home />
            <About />
        </Suspense>
    );
}

export default App;

Webpack配置如下：

module.exports = {
    // 其他配置
    optimization: {
        splitChunks: {
            chunks: 'async',
            minSize: 10000,
            minChunks: 1,
            cacheGroups: {
                asyncVendors: {
                    test: /[\\/]node_modules[\\/]/,
                    name: 'async - vendors',
                    priority: -10
                },
                asyncCommons: {
                    name: 'async - commons',
                    minChunks: 2,
                    priority: -20,
                    reuseExistingChunk: true
                }
            }
        }
    }
};

这里asyncVendors缓存组将异步导入的第三方模块提取到async - vendors.js文件中，asyncCommons缓存组将异步导入且至少被两个模块引用的公共模块提取到async - commons.js文件中。这样可以在用户访问相关路由时，只加载所需的模块，提高了应用的加载性能。

• 公共模块的提取：除了动态导入模块的优化，对于单页应用中的公共模块，如一些通用的工具函数、样式文件等，也可以通过设置splitChunks.chunks: 'initial'进行提取。例如，有一个utils.js文件被多个组件引用，可以将其提取出来：

// utils.js
export function formatDate(date) {
    // 日期格式化逻辑
    return date.toISOString();
}

// 在其他组件中引用
import { formatDate } from './utils';

function MyComponent() {
    const now = new Date();
    const formattedDate = formatDate(now);
    return <div>{formattedDate}</div>;
}

Webpack配置如下：

module.exports = {
    // 其他配置
    optimization: {
        splitChunks: {
            chunks: 'initial',
            minSize: 5000,
            minChunks: 2,
            cacheGroups: {
                commons: {
                    name: 'commons',
                    priority: -10
                }
            }
        }
    }
};

这样utils.js及其相关依赖就会被提取到commons.js文件中，避免在多个组件的打包代码中重复出现。

6. 优化过程中的常见问题及解决方法

6.1 打包文件数量过多

• 问题描述：在配置SplitChunksPlugin后，可能会出现打包文件数量过多的情况。这是因为过于细致的代码分割导致生成了大量小的chunk文件。例如，将每个小的公共模块都单独提取出来，虽然减少了重复代码，但增加了HTTP请求的数量。在浏览器中，每个HTTP请求都有一定的开销，过多的请求会导致性能下降。

• 解决方法：可以通过调整splitChunks.minSize和splitChunks.minChunks等配置项来解决。适当增大minSize的值，例如从默认的30KB增加到50KB或更大，这样可以减少生成的小chunk文件数量。同时，合理调整minChunks的值，比如将其从1提高到2或3，使得只有被多个chunk引用的模块才会被提取出来，进一步减少不必要的代码分割。例如：

module.exports = {
    // 其他配置
    optimization: {
        splitChunks: {
            minSize: 50000,
            minChunks: 2,
            // 其他配置
        }
    }
};

6.2 公共模块未被正确提取

• 问题描述：有时候，明明配置了SplitChunksPlugin，但某些公共模块并没有被提取出来，仍然在多个chunk中重复出现。这可能是由于配置的匹配规则不正确，或者模块的引用关系不符合预期。例如，缓存组的test规则设置错误，导致应该被提取的模块没有被匹配到。

• 解决方法：仔细检查splitChunks的配置，特别是cacheGroups中的test规则。确保test规则能够准确匹配需要提取的模块。可以使用调试工具，如在Webpack配置中添加devtool: 'eval - source - map'，这样在打包后可以通过浏览器的开发者工具查看模块的引用关系和打包情况，从而找出问题所在。例如，如果要提取node_modules中的lodash模块，但没有成功，可以检查test规则是否正确匹配lodash模块的路径：

splitChunks: {
    cacheGroups: {
        vendor: {
            test: /[\\/]node_modules[\\/](lodash)[\\/]/,
            name:'vendors',
            chunks: 'all'
        }
    }
}

6.3 缓存组优先级问题

• 问题描述：当配置了多个缓存组时，可能会出现模块没有按照预期被分配到相应的缓存组中。这通常是由于缓存组的优先级设置不合理导致的。例如，有两个缓存组groupA和groupB，groupA希望提取项目内部的公共模块，groupB希望提取第三方库，但由于优先级设置错误，一些项目内部的公共模块被错误地提取到了groupB中。

• 解决方法：正确设置缓存组的priority值。确保优先级高的缓存组能够优先匹配模块。例如，如果groupA的优先级应该高于groupB，则将groupA的priority设置为一个较大的值，如10，将groupB的priority设置为一个较小的值，如5：

splitChunks: {
    cacheGroups: {
        groupA: {
            priority: 10,
            // 其他配置
        },
        groupB: {
            priority: 5,
            // 其他配置
        }
    }
}

7. 性能监测与优化效果评估

7.1 使用工具进行性能监测

• Webpack Bundle Analyzer：这是一个非常实用的Webpack插件，可以生成可视化的打包文件分析报告。通过该报告，我们可以直观地看到每个模块在打包文件中的大小占比、依赖关系等信息。例如，我们可以清楚地看到哪些模块体积较大，是否存在重复打包的情况。安装该插件后，在Webpack配置中添加如下代码：

const BundleAnalyzerPlugin = require('webpack - bundle - analyzer').BundleAnalyzerPlugin;

module.exports = {
    // 其他配置
    plugins: [
        new BundleAnalyzerPlugin()
    ]
};

运行Webpack打包后，会自动打开一个浏览器窗口，显示打包文件的分析报告。从报告中，我们可以发现一些体积较大的模块，比如某个第三方库的体积过大，可以考虑是否有更轻量级的替代品，或者进一步优化该库的引入方式。

• Lighthouse：这是Chrome浏览器提供的一个开源的自动化工具，用于评估网页的性能、可访问性等方面。它可以模拟真实用户的访问情况，对页面的加载时间、资源大小等进行分析，并给出详细的优化建议。在Chrome浏览器中打开要测试的页面，然后在开发者工具中选择Lighthouse选项卡，点击“Generate report”按钮，即可生成性能报告。例如，报告中可能会指出某个打包文件体积过大，导致页面首次加载时间过长，这就提示我们需要进一步优化SplitChunksPlugin的配置，减小文件体积。

7.2 优化前后效果对比

• 文件体积对比：在优化之前，记录下打包文件的总体积。例如，通过查看打包后的文件大小，假设所有打包文件的总大小为500KB。在优化SplitChunksPlugin配置后，再次查看打包文件的总大小，可能会发现总大小减小到了400KB。文件体积的减小意味着用户在加载页面时需要下载的数据量减少，从而提高了加载速度。

• 加载时间对比：可以使用浏览器的开发者工具中的Performance面板来记录页面的加载时间。在优化前，记录页面从开始加载到完全渲染完成所需的时间，比如为5秒。优化后，再次记录加载时间，可能会发现加载时间缩短到了3秒。加载时间的明显缩短可以直接提升用户体验，使得应用程序更加流畅和高效。

通过性能监测和优化效果评估，我们可以不断调整SplitChunksPlugin的配置，以达到最佳的优化效果，提升前端应用的性能和用户体验。