Nginx Worker Process 通过零拷贝（sendfile）、事件驱动（epoll/kqueue）、内存池复用和 open_file_cache 等机制，实现静态资源的毫秒级响应与极低开销调度。
Nginx 的 Worker Process 处理静态资源请求，不是靠“读文件再发出去”这种常规方式，而是通过一套轻量、协同、内核级优化的机制，在毫秒内完成响应，同时保持极低内存与 CPU 开销。
Worker 进程不解析业务逻辑，只做路径匹配与零拷贝调度
每个 Worker 是单线程、事件驱动（epoll/kqueue）模型。收到一个静态请求（如 GET /js/app.js），它会：
- 立即在已加载的只读配置中匹配
server和location块，确定root路径和文件真实位置 - 调用
ngx_http_static_module模块执行try_files逻辑，检查文件是否存在、是否有权限 - 若文件存在且可读，不把内容读进用户空间，而是直接触发
sendfile()系统调用
零拷贝是核心动作，Worker 几乎不碰文件内容
-
sendfile on启用后，Worker 只向内核传递文件 fd 和偏移量，由内核从 page cache 直接复制到 socket 发送缓冲区 - 整个过程不分配用户态 buffer，不发生数据拷贝，也不触发上下文切换
- 配合
tcp_nopush on，确保数据攒够一个 TCP 报文段再发出，减少网络小包
内存开销被压到最低
- 请求开始时，从连接级内存池中划出一个子池，仅用于存放临时变量（如
$uri、MIME 类型、header 字符串） - 文件打开句柄、stat 结果等复用
open_file_cache，避免重复open()/stat()系统调用 - 请求结束，整个子内存池一次性归还，无逐个释放、无碎片
事件就绪即响应，不阻塞也不等待
-
sendfile提交后，Worker 立即返回事件循环，继续处理其他请求 - 内核完成传输后，通过 epoll 返回
EPOLLOUT或直接通知连接关闭 - 即使上万个 Keep-Alive 连接空闲，Worker 仍只监听有数据可收/可发的就绪事件
本质上，Worker Process 对静态资源的处理，是一次配置驱动的、内核协作的、内存可控的“元信息调度”，而不是传统意义的“文件服务”。
