worker_processes决定Nginx启动的Worker进程数量，影响CPU利用率、内存占用、连接分发均衡性及最大并发连接数，需结合worker_cpu_affinity、worker_rlimit_nofile等参数协同配置。
worker_processes 直接决定 Nginx 启动多少个 Worker 进程，是进程管理的起点——它不控制具体怎么干活，而是决定“派几个人去干活”。Master 进程读取这个值后，就按数拉起对应数量的独立 Worker 进程，每个都拥有完整配置副本、独立内存空间和事件循环，彼此不共享状态，靠操作系统调度竞争新连接。
worker_processes 决定进程数量与资源分配
设为 1，就只有 1 个 Worker 处理全部请求，CPU 多核闲置；设为 8（在 8 核机器上），就能让每个核心大致承载一个 Worker，提升并行效率。但若设成 16，系统就得频繁切换进程上下文，实际吞吐反而可能下降。每个 Worker 都会加载完整配置、缓存、连接结构体等，进程数翻倍，内存占用也基本翻倍。
影响连接分发与负载均衡机制
Nginx 使用“惊群”缓解机制（accept_mutex 默认开启），多个 Worker 会排队争抢新连接。worker_processes 越多，争抢队列越长，尤其在短连接高并发场景下，可能增加延迟抖动。合理数量能让连接更均匀落入各 Worker，避免单个进程过载或空闲。
制约整体并发能力上限
最大并发连接数 = worker_processes × worker_connections。比如 worker_processes 4、worker_connections 1024，理论上限就是 4096。如果只调大 worker_connections 却不增加 worker_processes，单个 Worker 很快会遇到文件描述符瓶颈或 CPU 调度瓶颈；反之，只堆 worker_processes 而不提升 worker_connections 或系统 ulimit，也会卡在连接数限制上。
关联其他关键进程行为参数
worker_processes 不是孤立存在的，必须配合以下设置才能发挥效果：
- worker_cpu_affinity：把每个 Worker 绑定到固定 CPU 核，减少迁移带来的缓存失效
- worker_rlimit_nofile：提高单个 Worker 可打开文件数，否则 worker_connections 设再高也没用
- events { worker_connections }：必须放在 events 块内，和 worker_processes 共同构成并发模型基础
- auto 值依赖系统识别准确——容器环境里若没限制 cgroup，它可能读到宿主机核数，导致误配
