遍历Promise是否会直接执行？Gmail API遇EMFILE错误解析

遇到的GaxiosError错误信息：

Uncaught GaxiosError Error: request to <gmail api url> failed, reason: connect EMFILE <xxx.xxx.xx.xxx:xxx> - Local (undefined:undefined)
    at _request (/gmail-api/node_modules/gaxios/build/src/gaxios.js:149:19)
    at processTicksAndRejections (<node_internals>/internal/process/task_queues:95:5)
gaxios.js:149
Process exited with code 1

错误仅在通过map生成Promise列表并使用Promise.all批量处理时触发，手动执行前10个请求则正常运行。触发错误的代码示例：

const promises = emailList.map((email) => {
      return this.gmailApi.users.messages.get({
        userId: 'me',
        id: email.id,
      })
    })

const resolvedPromises = await Promise.all(promises)

疑问：该问题产生的原因是什么？Node.js底层执行逻辑是怎样的？

错误本质 #

EMFILE错误是当前进程打开的文件描述符数量达到系统上限导致的。每个调用Gmail API的HTTP请求，在Node.js中都会占用一个系统文件描述符：当用map+Promise.all一次性发起大量请求时，瞬间创建的TCP连接会快速耗尽进程的文件描述符配额，新连接无法建立，最终抛出该错误。而手动执行10个请求时，数量远低于系统限制，因此不会触发问题。

Node.js底层执行逻辑 #

1. IO资源与文件描述符：Node.js依赖libuv处理网络IO，发起HTTP请求时，libuv会创建socket套接字，每个套接字对应一个系统文件描述符——系统用这个标识来管理进程打开的所有资源（包括文件、网络连接等）。
2. Promise.all的执行特性：Promise.all会同时触发所有传入的Promise执行，map遍历生成的每个Gmail API请求Promise会立即开始发起网络调用，短时间内大量socket被创建，文件描述符被快速占用。
3. 系统资源限制：操作系统对每个进程能打开的文件描述符数量有默认限制（例如Linux默认单进程上限为1024，macOS默认更高但仍有限），当进程打开的文件描述符数超过这个限制，内核会拒绝新的资源申请，最终表现为connect EMFILE错误。

解决思路 #

• 控制并发数：不要一次性发起所有请求，而是分批处理（比如每次处理10-20个），或者使用p-limit这类工具库限制同时运行的Promise数量，从根源上避免资源耗尽。
• 调整系统限制（不推荐优先使用）：临时或永久提高进程的文件描述符上限（例如Linux下用ulimit -n命令），但这种方式治标不治本，还可能引发其他资源占用问题。

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