前文提到：
P站认为 Fetch 不能跟踪下载进度，也没有提供拦截请求的方法，所以希望 Fetch 这个 API 能够改进。
经过文章讨论后，我们知道 fetch 是可以获取下载进度。但确实如P站所说，这个 Web API 有很大改善的空间。
文本将讨论 fetch 的相关细节，希望大家阅读后，能更加了解 fetch。包括：
- fetch 的易用性
- fetch 的使用优化
- fetch 的缺陷
fetch 的易用性
很多朋友会将 fetch 和 axios 进行比较，得出 fetch 仍然不够好用的结论。
但我认为，如果比较易用性，fetch 应该对比的是基于XHR（XMLHttpRequest）的 ajax。
上面代码可以看出，fetch 比原生 ajax 优雅不少。
如果拿 fetch 和 axios 作对比，无异于拿原生 ajax 和 axios 对比一样。未封装的底层 API 和封装好的包，在易用性上没有对比可言。
fetch 使用优化
在项目上，经常会对异常情况进行统一处理。
fetch 是基于 Promise，而它在网络、服务器出现错误使 reject，而对正常返回的请求，无论其状态码是 404 或 200，均会执行 resolve 的逻辑。
但实际项目上，我们一般对网络错误、服务器错误、后台找不到资源报 404、权限不足报 500 等，都执行同一种处理逻辑。
所以我们需要对 fetch 进行改造。
优化后的 fetch 流程，更加符合业务逻辑。
fetch 的缺陷
fetch 虽然作为“新出”的 API，但是却没得到开发者的普遍认同，原因有几点：
- 仅靠偏底层的原生 fetch，在易用性上，是无法和 axios 抗衡。
- fetch 的兼容性没 XHR 好。
- fetch 作为“新出”的 Web API，但是它并不是 XHR 的超集，部分 XHR 能提供的功能，例如跟踪上传进度，fetch 并不具备。
特别是第三点制约了 fetch。易用性，语法简单等都能通过封装完善，但是功能上的缺陷就难以修补。
fetch 的优势
虽然 fetch 的弊端不少，但是在一些场景下，还是体现出它的价值。
例如在我使用的代码转图片插件，它存在截图功能。这时候 fetch 配合 Clipboard API，就能不引入第三方包优雅地实现图片的复制。
结语
总的来说，实际项目 axios 更加适合，毕竟它所基于的 XHR 功能齐全，兼容性好，而且它还结合 Promise 的特点，同时解决了回调地狱等问题。
但 fetch 不需要引入第三方包、语法简单优雅的优点，在某些场景非常适合。
由于 fetch 和 Promise 密切相关，所以在面试中出现的频率非常高，是必须掌握的知识点。
你的点赞转发，是我创作的动力。欢迎评论区讨论，留言必回。
