worker_processes 应设为逻辑CPU核心数以匹配硬件；设少则压不住并发，设多则因上下文切换降低吞吐；推荐auto并配合worker_cpu_affinity、worker_connections等参数协同优化。
worker_processes 直接决定 Nginx 能否有效利用多核资源，是扩展性的底层支点——设少了压不住并发，设多了反而拖垮系统，关键不在“多”，而在“匹配”。
匹配 CPU 核心数是扩展性的基础
每个 worker 进程默认单线程、事件驱动，天然适合绑定一个 CPU 核心。当 worker_processes 等于逻辑核心数（含超线程），请求能均匀分发到各核，避免单核瓶颈；若设为 1，所有连接挤在一个进程里，再高的网络带宽也跑不满；若远超核心数（如 16 核设 32 个进程），调度器频繁切换上下文，实际吞吐可能下降 5%～15%。
- 查真实核心数用
nproc（容器内更准），而非/proc/cpuinfo（宿主机值） - 生产环境强烈推荐
worker_processes auto;，Nginx 1.3.8+ 自动读取并设为逻辑核心数 - 4 核 8 线程机器，通常设为 8；纯物理核无超线程则设为 4
影响横向扩展的隐性瓶颈
worker_processes 不只是进程数量，它会成倍放大内存与连接资源消耗：
- 每个 worker 独立加载配置、维护连接结构体、分配读写缓冲区（如
client_header_buffer_size），内存占用≈进程数 × 单进程开销 -
upstream keepalive连接池、open_file_cache、lua_shared_dict（未声明 shared 时）都是 per-worker 分配，进程越多，空闲连接和缓存副本越多 - 总并发能力 =
worker_processes × worker_connections，但若worker_connections没同步调高，扩进程也白搭
混合负载与特殊场景下的弹性调整
扩展性不是静态参数，得看服务器实际角色：
- 容器化部署：K8s 中 limits.cpu="2"，就必须手动写
worker_processes 2;，否则 auto 会取宿主机核数，导致资源争抢 - 与数据库共存：预留 1～2 核给 MySQL/PostgreSQL，设为
worker_processes $(nproc --all)-2;（需启动脚本支持） - 大量小文件 + 内存不足：文件总量远超 RAM 时，适当增加 worker 数（如 ×1.5）可提升磁盘 IO 并行度，但需同步调低
sendfile或增大read_ahead
必须配套的关键协同项
单独调 worker_processes 效果有限，要和这些参数联动才真正释放扩展潜力：
-
worker_cpu_affinity auto;：自动绑定进程到对应核心，减少跨核缓存失效（高负载下 QPS 可提升 8%～12%） -
worker_rlimit_nofile和events { worker_connections }：确保每个 worker 能打开足够文件描述符，否则扩进程后连接直接被拒 -
accept_mutex on;（Nginx 1.9.1+ 默认开启）：缓解惊群问题，让多个 worker 不争抢新连接，提升稳定性
