Nginx的Event Loop通过单worker内同步顺序执行、11阶段严格串行流水线及基于返回值的显式控制，确保单请求各阶段不交错、多请求间互不干扰，不保证全局请求顺序但保障每个请求生命周期完整有序。
Nginx 的 Event Loop 不保证“全局请求处理顺序”，而是通过单 worker 进程内事件的确定性调度 + 阶段化流水线 + 同步执行模型，确保单个请求内部各阶段严格有序、不交错，且多个请求之间互不干扰。它不追求请求 A 必须在请求 B 之前完成，但能确保每个请求从读取、解析、匹配、处理到响应的每一步都按既定逻辑顺序推进。
请求内部阶段流转是严格串行的
每个 HTTP 请求一旦被 accept 并初始化为 ngx_http_request_t 结构体，就会进入一个预定义的 11 阶段流水线（如 POST_READ → SERVER_REWRITE → FIND_CONFIG → REWRITE → … → CONTENT → LOG）。这些阶段：
- 按固定顺序执行，不可跳过或重排；
- 每个阶段内注册的 handler 按配置顺序依次调用；
- 当前阶段的 handler 返回值决定后续走向：
-
NGX_OK→ 自动进入下一阶段； -
NGX_AGAIN→ 暂停当前阶段，等待下次 I/O 就绪后继续； -
NGX_DECLINED→ 跳过当前阶段，进入下一阶段； -
NGX_ERROR或NGX_HTTP_XXX→ 终止流程，直接返回响应。
-
这种基于返回值的显式控制，让整个请求生命周期像一条单向传送带，不会出现“阶段 A 还没完，阶段 C 先跑起来”的情况。
单 worker 内事件回调是同步、顺序执行的
Nginx 的 Event Loop 不是并发回调模型，而是一个主循环主动拉取、顺序调用的过程：
-
epoll_wait()返回一批就绪事件后，worker 把它们放入就绪队列； - 然后逐个遍历该队列，对每个
ngx_event_t *执行ev->handler(ev)； - 这个调用是完全同步的：当前 handler 不返回，下一个事件就不会被执行；
- 因此，同一个连接上的读事件（如解析请求头）和写事件（如发送响应）绝不会并发执行，天然避免了竞态。
比如一个请求的完整路径可能是：ngx_event_accept → ngx_http_process_request_line → ngx_http_process_request_headers → ngx_http_core_run_phases（启动 11 阶段）→ ngx_http_writer，每一步都在前一步彻底结束后才开始。
多请求之间不争抢执行权，但共享资源需隔离
- 每个 worker 进程独立运行自己的 Event Loop，彼此不通信；
- 同一 worker 内，不同请求的事件会混在同一个就绪队列里，但因 handler 是绑定到具体连接（
c->read/c->write）的，所以调用时上下文完全隔离； - 没有锁、不共享连接状态，也就不存在“请求 A 修改了请求 B 的数据”这类问题；
- 请求处理顺序取决于：
- 内核通知就绪的先后（受网络延迟、TCP 排队影响）；
- worker 当前忙闲程度（是否正在处理长耗时操作，如 proxy_pass）；
- 定时器是否提前触发（如超时关闭）。
换句话说：Nginx 不承诺“先到先服务”，但承诺“每个请求自己走完自己的路，不被中途打断或污染”。
超时与中断也服从同一顺序逻辑
定时器不是独立线程，而是事件循环的一部分：
- 每次进入主循环前，先检查红黑树中是否有到期定时器；
- 若有，同步执行其 handler（如
ngx_http_set_keepalive），再处理就绪 I/O 事件； - 这些超时 handler 和普通事件 handler 一样，是同步调用、顺序执行的；
- 因此，一个请求可能在
ACCESS_PHASE被auth_basic拦下，也可能在CONTENT_PHASE前被client_header_timeout中断——但中断动作本身仍是流水线中的一环，不会插队或并发发生。
不复杂但容易忽略
