Nginx模块化本质是事件驱动下的声明式钩子协作机制：模块仅注册回调、不接管控制流，由配置驱动执行时机，按阶段链式调用，资源按需初始化，主进程与工作进程职责分离，核心与模块严格API隔离。
Nginx 的高扩展性模块化开发，本质是把功能拆解成“可插拔、不干扰、按需动”的独立单元，全部运行在统一的事件驱动骨架上。它不是靠堆模块数量，而是靠模块与事件循环之间干净、确定、低开销的协作机制。
模块只注册钩子，不接管控制流
每个模块（比如 rewrite、proxy、limit_req）不主动轮询、不创建线程、不阻塞等待 I/O。它只在编译或加载时向核心注册回调函数（如 postconfiguration、handler、filter），告诉 Nginx：“当走到某个阶段时，请调用我”。真正执行由工作进程在 epoll/kqueue 事件循环中统一调度——请求来了，状态机推进到 rewrite 阶段，就顺次调用所有已启用模块的 handler；响应要发出了，再依次过一遍 header filter 和 body filter。模块之间互不见面，只和核心约定好的接口打交道。
- 一个模块写错或卡住，不会拖垮整个事件循环，最多影响当前请求的该阶段处理
- 新增模块只需实现标准钩子函数，无需修改其他模块或核心逻辑
- 未启用的模块（比如配置里没写
proxy_pass）完全不参与任何阶段，零运行时开销
配置即调度指令，模块行为由声明式规则触发
模块本身不决定“什么时候运行”，而是由配置指令驱动。Nginx 把配置解析结果转化为明确的执行路径：遇到 limit_req 就激活限流模块的 preaccess 钩子；出现 add_header 就让头部过滤模块在输出前插入字段；配置了 try_files 就调用文件模块按序检查路径。这种声明式设计让模块介入点清晰、可预测，也便于核心在编译期优化状态机跳转，减少运行时判断分支。
- 同一模块可在不同上下文（server、location）中重复使用，行为由局部配置隔离
- 多个模块可按固定顺序链式协作（如 gzip → ssl → proxy），顺序由核心预设，不依赖模块间协调
- 第三方模块也能通过自定义指令（如
lua_code_cache）接入这套调度体系
模块资源按需初始化，避免启动膨胀
模块代码在加载时只做最轻量注册：填指令表、挂钩子函数指针。真正的内存分配、结构体初始化、连接池创建等操作，全推迟到配置解析完成后的 postconfiguration 阶段，并且仅针对实际启用的功能。例如 upstream 模块只有在配置中出现 proxy_pass 或 fastcgi_pass 时，才构建 upstream conf 和相关共享内存结构；否则整块逻辑静默，不占 CPU 也不耗内存。
- 动态模块（.so 文件）可随时加载/卸载，不影响正在运行的工作进程
- 模块上下文（main_conf、srv_conf、loc_conf）分层管理，作用域明确，避免全局污染
- 主进程只做配置解析和 fork，所有运行时资源都在工作进程中按需构造，天然支持热重载
核心与模块严格隔离，杜绝锁竞争
主进程只管读配置、拉工作进程、转发信号；所有网络 I/O、协议解析、内容生成，全由工作进程内模块协作完成。模块不能直接访问或修改核心数据结构（如 ngx_connection_t 的关键字段），只能调用标准 API（如 ngx_http_send_header()、ngx_chain_add_copy()）。这种契约式交互消除了跨模块数据竞争，使单个工作进程能稳定支撑数万并发连接，也大幅降低模块开发的复杂度。
- 模块开发者专注自身逻辑，不必操心线程安全、内存回收或事件分发
- 核心升级时，只要 API 兼容，已有模块无需改动即可继续运行
- 调试时可单独禁用某模块，快速定位是否为模块引入的问题
