我得到了一个基本要点，即CommonsChunkPlugin查看所有入口点，检查它们之间是否存在通用的软件包/依赖项，并将它们分成自己的捆绑包。

因此，假设我具有以下配置：

...
enrty : {
    entry1 : 'entry1.js', //which has 'jquery' as a dependency
    entry2 : 'entry2.js', //which has 'jquery as a dependency
    vendors : [
        'jquery',
        'some_jquery_plugin' //which has 'jquery' as a dependency
    ]
},
output: {
    path: PATHS.build,
    filename: '[name].bundle.js'
}
...

如果我捆绑而不使用 CommonsChunkPlugin

我将得到3个新的捆绑包文件：

• entry1.bundle.js包含来自entry1.js和的完整代码，jquery并包含自己的运行时
• entry2.bundle.js包含来自entry2.js和的完整代码，jquery并包含自己的运行时
• vendors.bundle.js包含来自jquery和的完整代码，some_jquery_plugin并包含自己的运行时

这显然很糟糕，因为我可能会jquery在页面中加载3次，因此我们不希望这样做。

如果我捆绑使用 CommonsChunkPlugin

根据我传递给CommonsChunkPlugin以下任何参数的参数，将会发生：

• 情况1：如果通过，{ name : 'commons' }我将得到以下捆绑文件：

  • entry1.bundle.js其中包含的完整代码entry1.js，是的要求，jquery并且不包含运行时
  • entry2.bundle.js其中包含的完整代码entry2.js，是的要求，jquery并且不包含运行时
  • vendors.bundle.js其中包含的完整代码some_jquery_plugin，是的要求，jquery并且不包含运行时
  • commons.bundle.js其中包含来自的完整代码jquery并包含运行时

  这样，我们最终得到了一些较小的包，并且包中包含运行时commons。不错，但不理想。

• 情况2：如果通过，{ name : 'vendors' }我将得到以下捆绑文件：

  • entry1.bundle.js其中包含的完整代码entry1.js，是的要求，jquery并且不包含运行时
  • entry2.bundle.js其中包含的完整代码entry2.js，是的要求，jquery并且不包含运行时
  • vendors.bundle.js其中包含来自jquery和的完整代码，some_jquery_plugin并包含运行时。

  同样，通过这种方式，我们最终得到了一些较小的包，但是运行时现在包含在vendors包中。由于运行时已包含在vendors捆绑包中，因此它比以前的情况要差一些。

• 情况3：如果通过，{ names : ['vendors', 'manifest'] }我将得到以下捆绑文件：

  • entry1.bundle.js其中包含的完整代码entry1.js，是的要求，jquery并且不包含运行时
  • entry2.bundle.js其中包含的完整代码entry2.js，是的要求，jquery并且不包含运行时
  • vendors.bundle.js包含来自jquery和的完整代码，some_jquery_plugin不包含运行时
  • manifest.bundle.js 其中包含其他所有捆绑包的要求并包含运行时

  这样，我们最终得到了一些较小的包，并且包中包含运行时manifest。这是理想的情况。

我不了解/不确定我是否了解

• 在案例2中，为什么我们最终得到了vendors既包含通用代码（jquery）又包含vendors条目（some_jquery_plugin）剩余内容的捆绑包？据我了解，CommonsChunkPlugin这里所做的是它收集了公共代码（jquery），并且由于我们强制将其输出到vendors捆绑软件中，因此它有点将公共代码“合并”到vendors捆绑软件中（现在仅包含来自some_jquery_plugin）。请确认或解释。

• 在案例3中，我不明白当我们传递{ names : ['vendors', 'manifest'] }给插件时发生了什么。为什么/如何vendors保持捆绑包完好无损，同时包含jquery和some_jquery_plugin，何时jquery显然是常见的依赖关系，以及为什么生成的manifest.bundle.js文件以创建方式创建（需要所有其他捆绑包并包含运行时）？

这就是CommonsChunkPlugin工作原理。

一个公共块“接收”由几个入口块共享的模块。在Webpack存储库中可以找到复杂配置的一个很好的例子。

它CommonsChunkPlugin在Webpack的优化阶段运行，这意味着它在内存被密封并写入磁盘之前就在内存中运行。

当定义了几个通用块时，将按顺序对其进行处理。在您的情况3中，就像两次运行插件一样。但请注意，它们CommonsChunkPlugin可能具有更复杂的配置（minSize，minChunks等），这会影响模块的移动方式。

情况1：

1. 有3entry块（entry1，entry2和vendors）。
2. 该配置将commons块设置为公共块。
3. 插件处理 commons公共块（由于该块不存在，因此将创建它）：
   1. 它收集其他块中多次使用的模块：entry1，entry2并vendors使用，jquery以便从这些块中删除该模块并将其添加到该commons块中。
   2. 该commons块被标记为entry，而该块entry1，entry2并且vendors块被作为未标记entry。
4. 最后，由于commons块是entry块，因此它包含运行时和jquery模块。

情况2：

1. 有3entry块（entry1，entry2和vendors）。
2. 该配置将vendors块设置为公共块。
3. 该插件处理vendors通用块：
   1. 它收集在其他块中多次使用的模块：entry1并entry2使用，jquery以便从这些块中删除该模块（请注意，vendors由于该vendors块已包含该模块，因此未将其添加到该块中）。
   2. 该vendors块被标记为entry，而该块entry1和entry2块旗标被作为entry。
4. 最后，由于vendors块是entry块，因此它包含运行时和jquery/jquery_plugin模块。

情况3：

1. 有3entry块（entry1，entry2和vendors）。
2. 该配置将vendors块和manifest块设置为公共块。
3. 该插件将创建manifest块，因为它不存在。
4. 插件处理 vendors通用块：
   1. 它收集在其他块中多次使用的模块：entry1并entry2使用，jquery以便从这些块中删除该模块（请注意，vendors由于该vendors块已包含该模块，因此未将其添加到该块中）。
   2. 该vendors块被标记为entry，而该块entry1和entry2块旗标被作为entry。
5. 该插件处理manifest公共块（由于该块不存在，因此将创建它）：
   1. 它会收集其他块中多次使用的模块：由于没有模块重复使用，因此不会移动任何模块。
   2. 该manifest块被标记为entry，而该块entry1，entry2并且vendors是未标记的entry。
6. 最后，由于manifest块是entry块，因此它包含运行时。

希望能帮助到你。