nginx 多进程架构通过 master 进程统一加载、校验并共享只读配置内存，worker 进程 fork 继承该副本，实现静态配置天然一致；reload 时原子切换新旧配置，无混用窗口。
Nginx 多进程架构本身不“分发”配置，而是通过 master 进程统一加载、校验并共享配置，所有 worker 进程直接使用同一份内存中的配置副本——静态配置的一致性由此天然保障，无需额外同步机制。
master 进程统一加载与广播
- master 读取 nginx.conf 后完成语法校验、路径解析、模块初始化等全部配置解析工作
- 配置结构体（如 http、upstream、server 块）被构建成只读的内存对象，存放于共享地址空间
- 启动或 reload 时，master 将该配置内存镜像直接 fork 给每个新 worker 进程（Linux 下采用写时复制机制，实际物理内存仍共享）
- 所有 worker 对 upstream、location、proxy_cache_path 等配置的引用，均指向同一块已解析好的内存区域
worker 进程无独立配置副本
- worker 不重复解析配置文件，也不读取磁盘 conf；它仅执行事件循环和请求处理逻辑
-
upstream中定义的负载策略、proxy_cache_path的缓存路径、root或alias的静态路径等，对所有 worker 完全一致 - 即使 worker 因异常退出重启，新进程仍从 master 获取当前最新配置（reload 后），不会残留旧配置
reload 机制确保原子切换
- 执行
nginx -s reload时，master 重新解析配置，生成全新配置内存结构 - 若校验失败，旧配置继续运行，新配置被丢弃，零风险
- 校验成功后，master 启动新 worker，并向旧 worker 发送退出信号；新旧 worker 之间无配置混用窗口
- 所有新 worker 同时启用新配置，旧 worker 逐步处理完剩余连接后退出
需注意的例外边界
- 某些运行时变量（如
$time_iso8601、$request_id）每次请求动态生成，不属于“静态配置”，不涉及一致性问题 - 使用
include引入的外部文件，必须确保所有 worker 能访问相同路径与权限；若 include 路径指向 NFS 或挂载点，需确认其一致性与可用性 - 日志路径（
access_log/error_log）虽属静态配置，但各 worker 写入独立文件（默认带 PID 后缀），这是设计行为，非不一致
不复杂但容易忽略
