要讨论Webpack 2中新增的这两个plugin的功能，还要先从使用Webpack打包的项目的前端资源缓存方案说起。
通常在使用了Webpack的项目中我们会使用CommonsChunkPlugin来将所有依赖的第三方包打包到一个名为vender的chunk中。与此同时，为了避免每次更改项目代码时导致venderchunk的chunkHash改变，我们还会单独生成一个manifestchunk。
举个例子，假设我们有一个项目，项目中入口文件为index.js。其内容如下：
importaddfrom'./src/add';importleftPadfrom'left-pad';importjsonpfrom'jsonp';add(1,2);
通常我们的webpack.config.js文件就会有类似如下的配置：
constpath =require('path');constwebpack =require('webpack');module.exports = {entry: {'app':'./index.js','vender': ['left-pad','jsonp'] },output: {filename:'[name].[chunkHash].js',path: path.resolve(__dirname,'build') },resolve: {extensions: ['.js'] },module: { ... },plugins:[newwebpack.optimize.CommonsChunkPlugin({name: ['vender','manifest'],minChunks:Infinity, }) ]};
这时，通过Webpack打包，会生成三个文件：
假设我们修改了./src/add.js文件，重新打包，会得到：
可以看到只有app和manifest这两个chunk的chunkHash改变了，而vender的chunkHash和之前保持了一致。这就使得vender可以被缓存在客户端，从而减少客户端的下载量。
但如果是新添加一个文件呢？
假设我们在项目中新加了一个文件./src/add2.js。此时index.js的内容如下：
importaddfrom'./src/add';importadd2from'./src/add2';importleftPadfrom'left-pad';importjsonpfrom'jsonp';add(1,2);add2(1);
此时再次构建，会得到如下的输出：
这就和我们期望的行为不一致了，因为我们并没有修改依赖的第三方包，但是venderchunk的chunkHash也发生了更改。
导致这个结果的原因在于，由于引入了一个新模块，使得打包过程中部分模块的模块ID发生了改变。而模块ID的改变，直接导致了包含这些模块的chunk内容改变，进而导致chunkHash的改变。
注意看下图：
蓝色框中的模块ID为3的模块就是我们新加的模块。由于它被插在了ID为3的位置，导致后续所有模块的ID都发生了更改。
既然找到了问题的原因，那么解决方案也就很明了了。那就是找到一种和顺序无关的模块ID命名方式。最容易想到的就是基于文件名或者文件内容的哈希值这两种方案了。其实也就是今天要说的NamedModulesPlugin与HashedModuleIdsPlugin的功能。
比如，我们在项目中启用HashedModuleIdsPlugin：
plugins:[newwebpack.optimize.CommonsChunkPlugin({name: ['vender','manifest'],minChunks:Infinity, }),newwebpack.HashedModuleIdsPlugin() ]
此时，再次构建项目得到：
可以看到各个模块的ID已经变成一小段哈希值。这时，在项目中添加./src/add2.js。重新构建，得到输出：
可以看出，两次构建之间，venderchunk的chunkhash以及各模块的模块ID都保持了一致。从而达到了最佳的缓存效果。
使用NamedModulesPlugin效果类似，此处不再演示。本文涉及的所有代码都可以在github上找到。
