nginx中核心模块与过滤模块通过职责分离和链式流转协同：核心模块构建环境、调度流程并初始化过滤链，过滤模块分阶段处理响应头与体，按配置静态插入不可逆流水线。
要理解Nginx模块化架构中核心模块与过滤模块如何协同完成数据处理，关键在于抓住“职责分离”和“链式流转”两个核心逻辑。核心模块不直接处理业务数据，而是搭建运行环境、组织调度流程；过滤模块则专注响应阶段的精细化加工，二者通过预定义接口和固定执行时序紧密咬合，形成一条不可逆、可插拔的数据流水线。
核心模块：构建骨架与启动调度
核心模块（如 ngx_http_module）是整个HTTP子系统的“总控台”，它不生成响应内容，但负责三件基础却不可替代的事：
- 解析配置并注册所有已启用的HTTP模块（包括handlers和filters），建立模块间的依赖关系
- 初始化全局过滤链指针（ngx_http_top_header_filter 和 ngx_http_top_body_filter），为后续链式调用铺好第一块路基
- 在请求进入HTTP处理阶段后，按固定顺序触发handler模块生成原始响应，再主动移交控制权给头部和包体过滤链
它像工厂的中央控制系统——不拧螺丝也不喷漆，但决定哪条产线开工、谁先上工、数据往哪送。
过滤模块：分阶段加工响应数据
过滤模块分为两类，严格按响应生成流程分工，且各自独立注册、不可互换：
-
头部过滤器（header filter）：在handler提交响应头后、尚未发送给客户端前被调用。典型用途包括添加/修改
Content-Type、X-Frame-Options、Strict-Transport-Security等头字段，或根据条件重写Location - 包体过滤器（body filter）：在响应体数据逐块生成时被反复调用（可能多次）。用于压缩（gzip）、HTML重写、敏感词过滤、图片动态裁剪等需操作实际内容的操作
每个过滤模块内部都保存着“下一个过滤器”的函数指针，处理完当前数据后，显式调用该指针完成接力。这种设计让任意模块可被跳过、替换或插入，而无需改动其他模块代码。
协同机制：从handler输出到客户端输出的完整路径
一次典型HTTP响应的数据流如下：
- handler模块（如 ngx_http_static_module 或 ngx_http_proxy_module）完成内容生成，调用
ngx_http_send_header()和ngx_http_output_filter() -
ngx_http_send_header()触发头部过滤链：从 ngx_http_top_header_filter 开始，逐级调用每个注册的头部过滤器，最终将处理后的头部交由网络层发送 -
ngx_http_output_filter()触发包体过滤链：对每一块待发送的响应体数据，从 ngx_http_top_body_filter 开始，依次经各body filter处理（如gzip压缩），最后交由 ngx_http_write_filter 写入socket缓冲区 - 整个过程完全异步非阻塞，头部可提前发出，包体边生成边过滤边发送，无等待、无拷贝冗余
配置与加载：模块协同的静态基础
模块能否参与这条流水线，取决于配置阶段的显式声明：
- 核心模块在
http{}块中加载所有HTTP模块，并依据模块自身声明的ngx_command_t commands[]解析其配置指令（如gzip on;启用 gzip_filter 模块） - 过滤模块必须在配置中启用（例如
gzip on;、sub_filter），才会被插入到对应过滤链中；未启用的模块完全不参与执行 - 多个同类型过滤模块的执行顺序由编译时链接顺序或模块注册顺序决定，通常可通过源码中
ngx_http_next_header_filter的赋值逻辑确认
这意味着，协同不是靠运行时协商，而是靠配置+编译期确定的静态拓扑结构保障的稳定性与可预测性。
