worker_processes 应设为 CPU 物理核心数或 auto，设少则多核闲置，设多则引发调度开销与缓存失效；必须配合 worker_cpu_affinity 绑定核心，并同步调优 worker_connections、worker_rlimit_nofile 及系统 ulimit 才能释放真实并发能力。
worker_processes 直接决定 Nginx 能否把请求“分摊”到多个 CPU 核心上干活——它不提升单个请求的速度，但决定了并发请求能被多少个进程同时处理。设得太少，再快的硬件也只用得上一个核；设得太多，进程抢着排队反而拖慢整体响应。
决定并行宽度，而非单点速度
每个 worker 进程是独立事件循环、不共享内存、各自监听端口（靠 accept_mutex 协调）。吞吐提升来自真正的并行：4 个 worker 在 4 核机器上，可同时处理 4 批连接；1 个 worker 再优化也只能串行扛压。
- 设为 1：所有请求挤在一个进程里，CPU 利用率永远卡在单核上限，%us 很低但延迟飙升
- 设为等于逻辑核心数（如 8）：请求较均匀分发，各核负载接近，吞吐随核心数线性增长（理想情况下）
- 设为远超核心数（如 16 核设 32）：调度器频繁切换上下文，实测 QPS 可能下降 5%～15%
放大资源消耗，间接制约吞吐上限
吞吐不是光看进程数，而是由 worker_processes × worker_connections 共同撑起理论天花板。但这个数字必须有底层资源支撑，否则只是纸面能力。
- 每个 worker 独立加载配置、缓存、SSL 会话池、open_file_cache —— 进程翻倍，内存占用基本翻倍
- 系统级文件描述符限制（ulimit -n）必须 ≥ worker_processes × worker_connections，否则新连接直接被拒
- 内核 net.core.somaxconn 应 ≥ worker_connections，否则连接在进入 Nginx 前就被丢弃
影响连接分发效率与稳定性
worker_processes 数量改变“争抢队列”的长度。在短连接高并发场景下，这点尤为敏感。
- 进程太少：单个 worker 忙不过来，连接排队等待时间变长，抖动明显
- 进程太多：accept_mutex 锁竞争加剧，唤醒/休眠开销上升，部分 worker 长时间空转
- 合理数量（匹配核心数）+ worker_cpu_affinity 绑定，能让连接更稳、更均衡地落入各 worker
需配合关键参数才真正释放吞吐潜力
单独调大 worker_processes 几乎没用，必须同步调整配套项：
- worker_cpu_affinity auto;：避免跨核迁移和缓存失效，高负载下 QPS 可提升 8%～12%
- worker_rlimit_nofile 和 events { worker_connections }：确保每个 worker 有足够文件句柄处理连接
- 容器或 K8s 环境中禁用 auto：按 limits.cpu 显式设置，防止读取宿主机核数导致资源争抢
