worker_cpu_affinity的核心价值是提升多worker高并发下的稳定性与效率，通过固定进程到特定CPU核心避免调度迁移导致的缓存失效和TLB刷新。
worker_cpu_affinity 的核心价值不是让单个请求变快，而是让多个 worker 在高并发下更稳、更高效。它通过把每个 worker 进程固定到特定 CPU 核心，避免 Linux 调度器频繁迁移进程——这种迁移会清空 L1/L2 缓存、刷新 TLB，带来明显延迟抖动，尤其在 NUMA 架构或长连接场景中影响更大。
怎么配才真正生效
绑定要起作用，必须满足三个前提：
- worker_processes 明确设为数字（如 worker_processes 4;），不能只写
auto（除非用worker_cpu_affinity auto） - CPU 掩码位数必须和 worker 数量严格一致：4 个 worker 就得写 4 个掩码，比如 0001 0010 0100 1000
- 掩码本身要合法：二进制位数不能超过系统实际逻辑 CPU 总数（可用
nproc或lscpu | grep "CPU(s)"确认）
推荐的写法与适用场景
不必硬背二进制，按场景选最稳妥的写法：
-
物理 4 核服务器：直接写
worker_processes 4;+worker_cpu_affinity 0001 0010 0100 1000; -
8 核以上且不想手算：用
worker_cpu_affinity auto;（Nginx 1.9.10+ 支持，自动按物理核顺序分配，避开超线程干扰） -
只想启用前 4 个物理核：写
worker_cpu_affinity auto 00001111;（后缀掩码限定可用范围） -
虚拟机或容器环境：优先用
auto配合 cgroup 限频/配额，硬绑定反而可能因宿主机调度失准导致负载不均
验证是否真的绑上了
别只看配置文件，运行起来再确认：
- 查各 worker 当前运行在哪颗核：
ps -eo pid,args,psr | grep 'nginx: worker'—— 第三列（psr）应是 0、1、2、3…一一对应 - 查某进程允许跑的 CPU 列表：
taskset -cp <pid></pid>—— 输出类似 pid 12345's current affinity list: 2 表示只允许在 CPU 2 运行 - 压测时观察
mpstat -P ALL 1：各核利用率应相对均衡，没有某核长期 100% 其他核空闲的情况
配套必须调的几项
单独开 worker_cpu_affinity 效果有限，需同步调整：
- 关闭 accept_mutex（1.11.3+ 默认已关）：否则 worker 仍会争抢 accept 锁，绑核也白绑
- 设好 worker_rlimit_nofile（如 65535）并同步配置系统 limits，否则连接数上不去
- 高并发建议开启 reuseport：让内核在 socket 层分发连接，彻底绕过用户态锁
- 避免把多个 worker 绑到同一核心（如写成
01 01），这等于人为制造争抢
