设 worker_processes auto 并搭配 worker_cpu_affinity auto 是提升多核转发性能最简明有效的组合，但需配合 NUMA 拓扑对齐、系统级中断绑定、资源限制调优及 Windows 特殊处理才能充分发挥效果。
直接设 worker_processes auto 并搭配 worker_cpu_affinity auto，是提升多核转发性能最简明有效的组合。但仅靠这两项远远不够——关键在于让每个 Worker 进程稳定驻留在专属核心上，同时避免跨核、跨 NUMA 节点的内存与中断干扰。
一、worker_processes 数量必须匹配真实可用逻辑核数
不能简单按物理核数设置，也不能盲目填大数字：
- 在 Linux 上用
nproc查看实际分配的逻辑 CPU 数（容器/云主机中常小于/proc/cpuinfo总数） - 设为
auto是首选，Nginx 1.3.8+ 会自动读取该值并 fork 对应数量进程 - NUMA 架构服务器（如双路 CPU）要特别注意：不建议设为总核数，而应设为单个 NUMA 节点的逻辑核数（例如每节点 32 核，则
worker_processes 32） - 设成 1 或远超核心数（如 64 核机器设 128），都会导致调度争抢或缓存失效，实测吞吐反而下降
二、worker_cpu_affinity 必须显式绑定，且掩码要对齐拓扑
Linux 调度器默认会动态迁移进程，导致 L1/L2 缓存频繁失效。固定绑定能提升缓存命中率 5%–10%：
- 基础写法（4 核）：
worker_cpu_affinity 0001 0010 0100 1000，每位对应一个 CPU ID，从右往左编号为 0、1、2… - 推荐写法（Nginx ≥ 1.9.10）：
worker_cpu_affinity auto，自动轮询绑定，比手写更可靠 - NUMA 场景下，
auto不感知节点边界，必须手动分组。例如双路 64 核（node0: 0–31, node1: 32–63），应写成两组 32 位掩码，确保所有 Worker 都落在同一节点内 - 掩码位数必须与
worker_processes数量严格一致，否则配置加载失败
三、配套系统级调优不可省略
即使 Nginx 配置完美，外部干扰仍会让亲和性失效：
- 关闭非必要服务（
cron、bluetoothd、avahi-daemon），减少定时中断和后台调度抢占 - 将网卡软中断（softirq）绑定到与 Nginx Worker 相同的 CPU 核心，避免网络包处理跨核搬运数据
- 调高文件描述符限制：
worker_rlimit_nofile 65535（配置中），配合ulimit -n 65535（启动前生效），并增大系统级fs.file-max - 禁用 swap：
swapoff -a，防止 Worker 内存被换出，引发毫秒级延迟突增
四、Windows 环境下的特殊处理
Windows 不支持 worker_cpu_affinity 指令，但仍有优化空间：
- 仍需设
worker_processes auto，确保启动足够数量 Worker 进程（如 8 线程就启 8 个） - 必须同步提高
worker_connections（建议 ≥4096）和worker_rlimit_nofile（如 65535） - 验证方式：用
tasklist /fi "imagename eq nginx.exe"查看进程数，应等于逻辑核数 + 1（master） - 避免使用 phpEnv 等集成环境的“平滑重启”，务必彻底停止再启动，否则新配置不生效
