为什么 fetch api 的 body 操作如 text json 是异步的

等待另一个 CPU 内核上的计算密集任务完成，和等待网络 I/O 上数据的传输，本质上是一样的，都应该抽象成异步 API ，以便主线程可以无阻塞运行

响应数据处理显然是个时间不可控的任务，类似的，JS 里的加解密 API 也是异步的

@autoxbc 这个还真不是计算任务，看我发的链接。就是网络 I/O 导致的，response 在 header 加载完成后就返回了，那会儿还没下载 body 呢。

这种 body 分离的设计是合理的，有一些需求不能按 OP 的想法直接一个 fetch 就返回整个 response

首先有的需求只需要获取 HTTP header ，不关心 body 是什么，那么浏览器只需要把 header 读取完即可返回，减少不必要的网络请求
其次是解析一个可能无限长的 body ，既一个很长时间才会出现（或者根本就不存在）「 0\r\n\r\n 」的 chunked transfer encoded body 。这种情况下除非出错，基本上很难等到 await 结束，而且可能在此之前内存就已经消耗殆尽。显然合理的做法是先读取完 header 返回然后让开发者调用 body 或者 arrayBuffer() 做流解析

像 .Net 的 HttpClient 也有这种设计，可以通过设定 HttpCompletionOption.ResponseHeadersRead 先读取完 Header 返回 HttpResponseMessage 再通过 Content 获取剩下的部分

java 的 vertx 框架的 httpClient 是先(request)connect 再 write body
或许 fetch api 是一样的原因？