worker_processes最佳值应为CPU物理核心数，推荐使用auto自动适配；需配合worker_cpu_affinity绑定核心，并同步调优worker_rlimit_nofile与系统ulimit以保障高并发能力。
worker_processes 最佳值不是固定数字，而是要让每个工作进程对应一个 CPU 物理核心，避免争抢又不闲置资源。设得太少会压垮单核，设太多反而引发频繁调度和缓存失效。
优先用 auto，而不是硬编码
直接写 worker_processes auto; 是最稳妥的选择。Nginx 1.3.8+ 能自动读取当前环境的 CPU 核心数，并据此启动对应数量的 worker 进程。这比手动写死更可靠，尤其在虚拟机、容器或云主机这类 CPU 可能被限制的环境中。
- 物理服务器：auto 通常等于物理核心数
- Docker 容器：官方镜像（如 nginx:alpine）内置脚本会读取 cgroups 的 cpu quota，auto 仍有效
- Kubernetes Pod：若设置了
resources.limits.cpu，需确认基础镜像支持 cgroups v2 检测，否则可能误判
手动设置时盯准物理核心数
如果必须手动指定，应以 物理核心数 为准，而非逻辑线程数（例如 8c16t 的机器，仍设为 8）。超线程对 Nginx 这类 I/O 密集型服务收益有限，还可能增加上下文切换开销。
- 查物理核心数命令：
grep -c 'core id' /proc/cpuinfo或nproc --all - 不建议设为 1（除非调试），也不建议超过物理核数的 1.5 倍
- 若服务器同时跑数据库等重负载服务，可酌情减 1–2 个进程留出余量
搭配 worker_cpu_affinity 绑定核心
启用 CPU 亲和性后，每个 worker 进程会固定运行在指定核心上，减少跨核缓存失效，提升 L1/L2 缓存命中率。高并发场景下实测延迟更稳、吞吐略升。
- 双核写法：
worker_cpu_affinity 01 10; - 四核及以上推荐：
worker_cpu_affinity auto;（Nginx 1.9.10+ 支持） - 注意：该指令需放在全局块（main context），且仅 Linux 有效
别忘了系统级配套调优
worker_processes 只是起点，它和连接数、文件描述符、内存共同构成并发能力闭环。光调进程数没用，必须同步检查：
-
worker_rlimit_nofile要 ≥ 单个 worker 的worker_connections - 系统 ulimit -n 至少设为
worker_processes × worker_connections的 1.2 倍 - 确保
events { use epoll; }在 Linux 上启用，避免 select/poll 低效回退
