Master进程不维护运行时配置树，仅一次性解析nginx.conf并生成cycle结构，再复制给各Worker；Worker各自持有一份只读副本用于请求处理，reload通过启停Worker实现配置原子切换。
在 Nginx 的多进程模型中，Master 进程并不维护运行时的配置解析树，它只负责初始加载、语法检查和配置解析，并将解析后的结构（如指令上下文、模块配置等）传递给 Worker 进程；之后 Master 进程不再持有或更新该结构，也不参与请求处理。
Master 进程的核心职责是配置加载与进程管理
Master 进程启动时会读取 nginx.conf，调用各模块的 create_main_conf、create_srv_conf、create_loc_conf 等钩子函数，构建完整的配置结构体树（如 ngx_conf_t 驱动下的 ngx_cycle_t → conf_ctx）。但这一过程是一次性的：
- 配置解析完成后，Master 将初始化好的 cycle 结构（含所有模块配置）通过
ngx_init_cycle()构建并复制给每个 Worker 进程 - Worker 进程各自持有一份独立、只读的配置副本，用于实际处理请求
- Master 本身不保留配置树的运行时引用，也不响应配置变更——reload 操作本质是启动新 Worker、优雅关闭旧 Worker，而非“热更新”Master 内的树
配置重载时，Master 不复用旧解析树
执行 nginx -s reload 时：
- Master 进程重新打开配置文件，再次调用全部模块的解析函数，生成一套全新的配置结构
- 若解析失败，新 cycle 构建中断，旧 Worker 继续运行，Master 不切换
- 仅当全部校验通过，Master 才 fork 新 Worker，并向旧 Worker 发送
QUIT信号；新旧 Worker 完全隔离，配置树无共享
为什么设计为“Worker 各自持有一份配置”？
这种设计服务于 Nginx 的高并发、无锁目标：
- 避免多进程间同步配置树带来的锁开销和复杂性
- Worker 可直接访问本地内存中的配置，无需 IPC 或共享内存协调
- 配置变更天然具备原子性：要么全部生效（新 Worker 启动成功），要么维持原状（旧 Worker 不受影响）
所以准确地说：Master 进程负责解析并生成配置树，但不维护它；真正持有并使用配置树的是每个 Worker 进程。这是理解 Nginx reload 行为、模块开发及调试配置问题的关键前提。
