Nginx Master进程依据配置文件中worker_processes指令的值静态确定Worker数量：解析数字、auto或on，auto时读取物理CPU核心数，然后一次性fork指定数量子进程，不支持运行时动态增减。
Nginx 的 Master 进程本身不“动态分配” Worker 数量，而是严格依据配置文件中 worker_processes 指令的值，在启动时一次性 fork 出指定数量的 Worker 进程。这个过程是静态、确定性的，不是运行时按负载伸缩的。
它怎么知道该起几个 Worker？
Master 进程在启动初期就完成三件事：
- 读取
nginx.conf中的worker_processes指令 - 解析其值（数字、
auto或on） - 根据结果计算出最终进程数，然后调用
fork()创建对应数量的子进程
比如：
-
worker_processes 4;→ 启动 4 个 Worker -
worker_processes auto;→ 读取/proc/cpuinfo中的 物理 CPU 核心数（非超线程逻辑核），设为进程数 -
worker_processes 1;→ 只起 1 个 Worker（默认值）
为什么不能运行中增减 Worker 数量？
因为每个 Worker 进程都持有独立的事件循环、连接池、内存空间和监听 socket 副本（通过 SO_REUSEPORT 或 accept_mutex 协调）。新增或销毁 Worker 需要重新初始化资源、重分连接、同步状态——Nginx 没有内置热扩缩机制。你只能通过 nginx -s reload 触发全量重启 Worker：旧 Worker 处理完已有请求后退出，新 Worker 按新配置启动。
关键细节：
- Master 不参与请求处理，只做监管（如收到
SIGHUP就重走配置加载 + fork 流程） - 所有 Worker 在 fork 时获得完全相同的配置快照，行为一致
-
worker_cpu_affinity是 Master 在 fork 前设置的调度策略（如0001 0010），让每个 Worker 绑定到特定 CPU 核，避免上下文切换开销 - 如果
worker_processes设得远超 CPU 核心数（比如 64 个 Worker 跑在 4 核机器上），反而会因调度竞争导致性能下降
常见误操作提醒：
- 修改
worker_processes后只执行nginx -s reload，不会生效——必须先nginx -s stop再nginx，或确保 reload 触发的是完整重启（取决于是否启用master_process on且无残留进程） - 不要依赖
ps aux | grep nginx看到的进程数来判断实际 Worker 数：Master 进程也计入，需过滤nginx: worker process
本质上，Master 对 Worker 数量的“分配”，就是忠实执行配置 + 精准 fork，背后没有算法决策，只有明确指令与系统资源的对齐。
