Nginx 无传统异步回调链，其异步基于事件驱动+非阻塞I/O+状态机，所有handler由核心按事件调度调用，生命周期严格绑定请求或连接上下文，内存由分层pool统一管理并随上下文销毁自动释放。
在 Nginx 中，并不存在传统意义上“异步回调链条”的抽象概念——它不提供类似 Node.js 的事件循环 + 回调队列模型，也没有用户可直接注册和管理的长生命周期回调链。Nginx 的异步本质是基于 事件驱动 + 非阻塞 I/O + 状态机 的协作式并发模型，所有“回调”都是由核心调度器在特定事件（如 read ready、write ready、timer expire）触发时，调用模块预设的 handler 函数。其生命周期与内存管理严格绑定于请求（ngx_http_request_t）或连接（ngx_connection_t）上下文，由 Nginx 内存池（pool）统一管控。
请求生命周期决定回调执行边界
Nginx 的 HTTP 模块处理逻辑围绕一个请求展开，从接收完整请求行/头开始，到发送完响应并关闭连接（或进入 keepalive）结束。所有模块注册的 handler（如 rewrite_handler、access_handler、content_handler、output_filter）都在该请求生命周期内被顺序或条件调用。一旦请求结构体被销毁（ngx_http_finalize_request → ngx_http_free_request），其关联的所有回调函数指针即失效，不会再被调用。
- 没有“脱离请求存在的全局回调”；定时器回调（
ngx_add_timer）也必须显式绑定到某个 pool 或 connection，且需自行确保其回调函数访问的数据仍有效 - 子请求（subrequest）拥有独立的
ngx_http_request_t和内存池，其回调仅在其子请求生命周期内有效 - 若在 handler 中启动异步操作（如 upstream 转发、cosocket 调用），Nginx 通过挂起当前请求（
ngx_http_set_ctx+ngx_http_core_run_phases暂停）、等待事件就绪后恢复执行，本质仍是请求状态机的延续，不是回调链传递
内存池（pool）主导内存分配与自动释放
Nginx 不依赖 GC 或引用计数，而是使用分层内存池：主 cycle pool、connection pool、request pool。每个请求拥有专属的 r->pool，所有模块在该请求中申请的内存（包括回调闭包所需的数据结构、临时 buffer、上下文 ctx）均从此 pool 分配。
- 请求结束时，
ngx_destroy_pool(r->pool)一次性释放整个 pool 所有内存，无需逐个 free —— 这意味着你不能把指向 request pool 内存的指针长期保存在全局变量、静态变量或跨请求上下文使用 - 若需跨请求或长期持有数据（如缓存、共享内存段），必须显式分配到
cycle->pool、shm或堆内存（ngx_alloc），并自行管理生命周期 - upstream 模块中常见的
u->buffer、u->headers_in等结构，均由 request pool 分配，随请求销毁而释放
异步操作（如 upstream、cosocket）的“伪回调”实现
以 upstream 为例：当调用 ngx_http_upstream_init 后，Nginx 并不立即执行回调，而是将 upstream 请求挂载到当前连接的读写事件上。待 upstream socket 就绪，事件循环调用 ngx_event_pipe_read_upstream 或 ngx_http_upstream_process_header，这些函数内部再调用模块设置的 input_filter、process_header 等钩子——它们不是被“回调”，而是被“调度执行”。整个过程无回调函数注册表，无栈式回调链，只有状态迁移与函数指针的直接跳转。
- 模块开发者需在初始化阶段将函数地址存入 upstream 结构体（如
u->input_filter = my_input_filter），Nginx 核心按状态调用，不保存调用栈 - 所有中间状态（如解析 header 的临时变量、body 缓冲区）都应分配在 request pool 中，由 Nginx 自动回收
- 若在 filter 中需要暂存数据供后续 filter 使用，应通过
ngx_http_set_ctx(r, ctx, module)将 ctx 存入 request，而非 malloc 后手动管理
避免常见生命周期陷阱
多数内存错误和崩溃源于对 Nginx 生命周期模型的误用：
- 不要在 request pool 中分配需跨请求存活的对象：例如在 rewrite 阶段 malloc 一块内存并存入全局 map，请求结束后该内存已被释放，后续访问即 use-after-free
-
不要在 timer 回调中直接访问已结束请求的字段：即使 timer 是为某请求添加的，也要在回调开头检查
r != NULL && !r->done，否则可能访问已释放的 request 结构体 -
不要在 output_filter 中修改或释放上游传入的 buffer 内存：upstream 已将其分配在自己的 pool 中，filter 只读访问；如需改写，应使用
ngx_chain_get_free_buf从当前 request pool 获取新 buffer -
第三方模块（如 lua-nginx-module）封装了更高级的协程语义，但底层仍受制于 Nginx 请求/连接生命周期：ngx.timer.at 创建的定时器回调，其第一个参数是包含 request 引用的 table，但该 request 可能已在定时器触发前完成；必须用
req:completed()判断有效性
