JavaScript中请求与函数异步的成因及相关疑问

一、API请求异步的核心原因 #

API请求的异步特性本质源于网络IO的耗时特性，而非单纯由前端的Promise/async await处理方式或服务器的异步处理逻辑导致——两者只是和异步相关，但并非根源：

• 当客户端发起HTTP请求时，需要通过网络传输数据到服务器，再等待响应返回，这个过程会消耗不确定的时间（比如网络延迟、服务器处理耗时）。如果同步执行该操作，主线程会被阻塞，页面或程序会失去响应，因此必须设计为异步模式，让主线程能继续处理其他任务。
• 前端使用then()或async/await，只是异步操作的语法糖与优雅处理方式，用来更顺畅地处理异步结果，而非“让请求变成异步”的原因。哪怕不用这些语法，直接用XMLHttpRequest的回调函数，请求依然是异步的。
• 服务器的异步处理是其自身的并发策略（比如线程池、事件循环），目的是提升吞吐量，但这和前端请求的异步性无关——哪怕服务器同步处理每个请求，前端的网络请求依然是异步的，因为网络IO本身就是耗时的非阻塞操作。

二、为何部分异步函数无需Promise #

setTimeout()和fs.readFile()这类函数属于早期异步API，它们基于回调函数模式实现异步，而Promise是ES6才引入的异步规范，初衷是解决回调地狱问题：

• setTimeout()是浏览器/Node.js的定时器API，它会将回调函数放入事件队列，等待指定时间后由事件循环执行，全程不阻塞主线程，这是基于事件循环的异步机制，无需Promise即可实现。
• fs.readFile()是Node.js的文件IO API，文件读取属于耗时IO操作，Node.js会将其交给底层IO线程处理，完成后通过回调函数通知主线程，同样是基于事件循环的异步模式，在Promise普及前就已存在。

后来为了统一异步操作的处理方式，Node.js推出了fs.promises.readFile()这类Promise封装版本，浏览器也用fetch（基于Promise）替代早期XHR，本质都是为了让异步代码更易维护，而非异步机制本身依赖Promise。

内容的提问来源于stack exchange，提问作者newlearner