还记得第一次接触webpack的时候，以为它是来拯救世界的，稍有了解后发现只能以玄学配置，佛系三问来相处。很幸运，最近傻BubbleM又有机会开始踩webpack的坑了。。。
掉坑描述
在scss文件中使用background-image: url('./../../../images/icon/left.png');为元素设置背景图片。
Q：
- 使用
background-image:url('...');背景图片不加载，使用background:red;却正常显示？？？ -
控制台报404
图片404
探索出坑
查看打包后的文件，发现图片被直接打包在了dist打包后的根目录下，而图片请求地址却在子目录下。
Q： 我并没有配置图片打包输出的路径啊，这是？
A：
- 方案一
当引用一个图片/文件的时候，webpack会自动将其导入到output文件夹下。文档说明。
但是根据scss中使用的相对当前文件引入的图片编译后路径是使用当前scss文件的打包后文件目录，二者的不一致导致图片访问404。
output有个publicPath配置项，默认为""，为其设置一个值后期编译后图片路径将在publicPath下。
添加publicPath
图片加载正常，问题解决。
-
方案二
使用url-loader
使用url-loader由于此次图片较小，可以解决。但是如果图片较大还是需要方案一二结合处理。
Q：图片名是否可以不压缩？
A：webpack处理图片会自动将图片名字做一个哈西编码压缩。可更改配置{ test: /\.(png|jpg)$/, use: 'file-loader?name=[name].[ext]&' }即可
file-loader
webpack最终会将各个模块打包成一个文件，故打包后样式中的url路径是相对入口html页面的，而不是相对于原始css文件所在的路径的。这就会导致图片引入失败。这个问题是用file-loader解决的，file-loader可以解析项目中的url引入（不仅限于css），根据我们的配置，将图片拷贝到相应的路径，再根据我们的配置，修改打包后文件引用路径，使之指向正确的文件。
如果图片较多，会发很多http请求，会降低页面性能。
url-loader
url-loader会将引入的图片编码，生成dataURl。相当于把图片数据翻译成一串字符。再把这串字符打包到文件中，最终只需要引入这个文件就能访问图片了。当然，如果图片较大，编码会消耗性能。因此url-loader提供了一个limit参数，小于limit字节的文件会被转为DataURl，大于limit的还会使用file-loader进行copy。url-loader封装了file-loader。
本人才学疏浅，正处菜鸟晋升阶段，文章如有错误表述希望大佬们多多指出。
