从前面可以看到dll带来的优点，但并不意味着我们就应该把除业务代码外的所有代码全部都丢到dll中，举一个例子：
1.对于lodash这种第三方库，正确的用法是只去import所需的函数（用什么引什么），例如：
// 正确用法 import isPlainObject from 'lodash/isPlainObject' //错误用法 import { isPlainObject } from 'lodash'
这两种写法的差别在于，打包时webpack会根据引用去打包依赖的内容，所以第一种写法，webpack只会打包lodash的isPlainObject库，第二种写法却会打包整个lodash。现在假设在项目中只是用到不同模块对lodash里的某几个函数并且没有对于某个函数重复使用非常多次，那么这时候把lodash添加到dll中，带来的收益就并不明显，反而导致2个问题：
由于打包了整个lodash，而导致打包后的文件总大小（注意是总大小）比原先还要大
在dll打包太多内容也需要耗费时间，虽然我们一般只在第三方模块更新之后才进行重新预编译（就是dll打包的过程），但是如果这个时间太长的话体验也不好、
实践与反思
放一张自己在一个比较大的项目中单纯使用dll之后的收益，提取的内容是 react相关的第三方库，和fish组件，构建时间从120s降低到80s左右（当然这个时间还是有点恐怖），构建前appjs的大小是680kb，拆分业务代码和第三方代码分别是400kb和380kb（这就是拆分后大小大于拆分前大小的例子），从这一点来看，对于常见第三方库是否要放进dll可能比较明确（比如react系列打包一般肯定不亏），但是还有一些就要结合具体的项目内容来进行判断和取舍。（强烈推荐使用webpack-bundle-analyzer插件进行性能分析）
总结
本文介绍了Dllplugin的思想,基本用法和应用场景(关于使用的部分更详细的内容可以看官方文档)，结合个人的一些实践经验，对于常见第三方库是否要放进dll可能比较明确（比如react系列打包一般肯定不亏），但是还有一些就要结合具体的项目内容来判断，例如我上面的实践的例子就说明目前的拆分还不够好。这一块也欢迎大家一起探讨。