Node.js事件循环管理及请求-任务关联、请求本质技术疑问

问题1：请求发送至HTTP服务器时，对应新连接、新进程还是新线程？ #

• 默认情况下，Node.js HTTP服务器基于单进程单主线程运行，不会为每个请求创建新进程或线程。
• 每个请求会对应一个新的TCP连接（HTTP/1.1及以上默认开启keep-alive，可能复用已有连接处理多个请求，但单个请求仍属于独立的请求上下文）。
• 所有请求的处理逻辑都在主线程的事件循环中调度执行，靠非阻塞I/O和异步回调实现高并发；只有手动使用cluster模块开启多进程，或worker_threads开启多线程时，才会出现多进程/线程处理请求的情况，这属于性能扩展手段，并非默认行为。

问题2：事件循环如何识别异步任务关联的具体请求？ #

你提到的“ID映射”思路并非Node.js的实现方式，核心逻辑是闭包捕获请求上下文：

• 请求到达时，Node.js会创建对应的req（请求对象）和res（响应对象），这两个对象包含了该请求的所有上下文信息（如套接字、请求头、客户端标识等）。
• 发起异步任务（比如fs.readFile、数据库查询）时，传入的回调函数会闭包捕获当前的req和res对象。
• 事件循环仅负责调度异步任务的回调执行，当异步任务完成后，回调函数直接使用捕获到的res对象发送响应，自然就能精准对应到发起请求的客户端——不需要额外的全局ID映射。
• 操作系统层面，每个TCP连接有唯一的套接字描述符，Node.js底层的libuv库会管理这些套接字，当套接字有数据就绪或任务完成时，会通知事件循环触发对应的回调，而回调本身已经绑定了请求上下文，因此不会出现响应发错的情况。

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