前文提到：
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 密切相關，所以在面試中出現的頻率非常高，是必須掌握的知識點。
你的點贊轉發，是我創作的動力。歡迎評論區討論，留言必回。
