最优值取决于cpu物理核心数、业务类型和部署环境，推荐设为worker_processes auto；物理核数需通过lscpu命令计算，cpu密集型场景可设为物理核数或略高，i/o密集型4～8个足够，容器化环境须按分配vcpu数手动设置，并同步调整worker_rlimit_nofile等参数。
最优值不是固定数字，而是取决于你的 CPU 物理核心数、业务类型和部署环境。目前最稳妥、最推荐的做法是直接写 worker_processes auto; —— Nginx 会自动读取系统物理核心数并设为对应进程数，省心且适配性好。
看硬件：优先按物理核心数来
别被超线程（比如 8 核 16 线程）迷惑。Nginx 是 I/O 密集型服务，多数场景下不需要匹配逻辑核数。用下面命令查真实物理核心总数：
- lscpu | grep "Core(s) per socket" && lscpu | grep "Socket(s)" → 相乘得物理核数
- 例如：2 路 CPU × 6 核/路 = 12 物理核 → 初始可设 worker_processes 12;
看用途：不同负载类型有差异
CPU 密集型（如大量 HTTPS 加解密、实时压缩、OpenClaw 类 Agent 推理网关）：建议设为物理核数或略高，避免频繁切换；
I/O 密集型（静态文件、反向代理、缓存命中率高）：4～8 个进程往往已够用，再多提升有限；
混合型（HTTPS + 动态 upstream）：从物理核数起步，再用 wrk 或 ab 压测，观察 QPS 和 CPU idle 率来微调。
看环境：特殊部署需手动指定
容器化（Docker/K8s）不能依赖 auto —— 容器看到的是宿主机全部 CPU，但实际被 cgroups 限制。应根据分配的 vCPU 数显式设置，比如限制了 2 个 vCPU，就写 worker_processes 2;；
云主机若只配了 1 核，设成 4 反而引发严重上下文切换，拖垮性能；
调试或极低负载时可用 1，但生产环境不建议。
配套参数必须同步调整
单设 worker_processes 不够，还要配平关联项：
- worker_rlimit_nofile 必须 ≥ worker_connections（通常设为 65535 或更高）
- events { worker_connections 4096; use epoll; multi_accept on; }
- 高并发反向代理可尝试 worker_processes = 物理核数 + 1～2，但要压测验证
