Nginx HTTP过滤模块是事件驱动中响应生成阶段的确定性环节，header_filter与body_filter链严格分时执行，通过函数指针跳转实现无调度链式处理，依赖请求周期内存管理和事件阶段隔离。
理解 Nginx HTTP 过滤模块的链式流处理，关键不在于单独看 filter 代码，而在于把它放进事件驱动的整体节奏里——filter 链不是独立流水线，而是事件循环中“响应生成阶段”的确定性一环。
事件驱动决定了 filter 的触发时机和不可中断性
Nginx 主循环基于 epoll/kqueue 等机制监听 socket 事件。当 upstream 返回响应（如 FastCGI、proxy_pass）后，会触发一个“可写”或“完成”事件，进而进入 output 阶段：
- 先调用
ngx_http_send_header()：触发 header_filter 链执行，最终必须调用ngx_http_write_filter把头部真正写入连接缓冲区 - 再调用
ngx_http_output_filter()：触发 body_filter 链执行，每次上游提供一批数据（可能只是部分 body），就走一遍链表 - 整个过程在单次事件回调内同步完成，不能 sleep、不能阻塞 I/O、不能等待外部响应
Filter 链是事件上下文中的静态函数指针链
filter 模块不参与事件注册，也不创建新事件。它的“链式”本质是两个全局函数指针的跳转：
-
ngx_http_top_header_filter和ngx_http_top_body_filter是链首入口 - 每个模块初始化时“劫持”这两个指针：保存原值到自己的
static ngx_http_next_*，再把自己的函数地址赋给全局指针 - 执行时，当前 filter 处理完，直接调用自己保存的
next函数——这是纯函数调用，无调度、无队列、无状态切换
链式流处理依赖事件阶段的严格分界
header 和 body 的过滤链不是并行或混合的，而是由事件驱动流程强制隔离：
- header_filter 链必须在第一个 body_filter 调用前执行完毕，否则
r->header_sent不置位，后续 body 写入会失败 - body_filter 可被多次调用（对应多次 upstream 数据到达事件），每次接收一个
ngx_chain_t *，但必须正确识别buf->last_buf标志来判断是否为终帧 - write_filter 作为链尾，才是真正把内存/文件 buf 提交到 socket 发送缓冲区的唯一出口——它把 filter 流处理结果，交还给事件循环管理的连接写事件
实际开发需匹配事件生命周期管理资源
在 filter 中分配内存、记录状态，必须与请求事件周期对齐：
- 用
r->pool分配内存（如注入脚本内容），确保随请求释放，不泄漏 - 用
r->main_filter_ctx或自定义 ctx 存储跨多次 body_filter 调用的状态（如 HTML 解析状态机） - 避免在 filter 中做耗时操作（如正则全量匹配大文本），否则会卡住整个事件循环，影响其他连接
