url-loader 和 file-loader 都可以处理图片资源
file-loader 和 url-loader 在 webpack5 中基本都不怎么用了，有其他更简便的替代方案。

特点：可以将较小的文件，转成 base64 的 URI。（意味着到时候可以和我们的网页一起请求下来，因为这些图片转换过后的base64的URI都会被嵌入到bundle.js文件中，到时候与js文件一起被请求）
image.png

image.png

Q：用url-loader 处理图片，npm run build后，发现build文件夹下并没有打包后的图片，那图片打包成功了吗？

打包成功了。但它打包的方式跟 file-loader 的打包方式不一样。url-loader 会默认将所有的图片资源转换成 base64 的data，这些内容将会被直接嵌入到 bundle.js 文件中（浏览器是可以直接解析base64的数据的，那么就会成功展示图片了）

base64编码

image.png

Q：但是，url-loader这种直接将图片转换成base64 的方式，相对于file-loader将图片复制到build文件夹下，好还是不好？

并不是很好。
因为在开发中，我们往往是 小的图片需要转换成base64， 但是大的图片是直接使用图片的。（大的图片单独放在一个文件夹下，单独发送http请求；小的图片为了减少http请求的发送次数，一般采用base64编码的方式）

这是因为小的图片转换base64之后可以和页面一起被请求，减少了不必要的请求过程；而大的图片如果也转换base64的话，反而会影响页面的请求速度（但是需要更多的http请求）

:::info url-loader 和 file-loader 的区别
url-loader原理：将图片转换成base64的URI，然后将这些转换过后的URI嵌入到 bundle.js文件中。
file-loader原理：直接将图片复制到build或dist 文件夹下，然后进行重命名。 ::: :::info url-loader的限制
假如，我们现在把所有的图片（大图片、小图片）都通过url-loader转换成base64的data，那这些base64 的data 都会被放到bundle.js 文件中，那该文件体积就会非常大，那么网页在加载该bundle.js 文件的时候就会花很长时间（加载非常慢） ::: :::info file-loader 的限制
会发送更多的http请求，无论是对客户端，还是服务器端，都会造成较大的压力 :::

Q：那我们如何限制哪些大小的图片转换和不转换呢（即大图片单独放在一个文件夹下，小图片需要转换成base64）

在 webpack.config.js 配置文件中，url-loader有一个options属性 - limit 属性，可以用于设置图片转换的限制
limit属性值是一个数值（单位是byte，字节）
例如：我们要求体积小于 100kb 的图片在打包的时候被转换成base64的URI；而体积大于100kb的图片，需要放在单独的img文件夹下。
image.png
image.png