用lscpu确定worker_cpu_affinity掩码需按逻辑CPU编号映射二进制位序：最右位（LSB）对应CPU 0，向左依次递增；总位宽等于CPU(s)总数，同一物理核的逻辑核位不可同时置1，否则丧失独占性。
用 lscpu 算准 worker_cpu_affinity 掩码，关键不是数“几位”，而是把输出里的 CPU 拓扑映射成二进制位序——错一位，整个绑定就失效。
先抓真实逻辑核数和编号范围
运行：lscpu | grep -E "CPU\(s\)|On-line|NUMA|Thread|Core|Socket"
重点关注三行：
-
CPU(s): 这是系统识别的总逻辑 CPU 数（含超线程），比如显示
12，说明有 12 个可调度的逻辑核，编号就是0–11；掩码每组必须是 12 位 -
On-line CPU(s) list: 显示实际启用的核心范围，如
0-11或0,2,4,6,8,10。若为后者，说明部分核心被禁用，掩码长度仍按CPU(s)总数来，但只在对应位置置 1 -
Thread(s) per core: 若为
2，说明开了超线程；若为1，逻辑核 = 物理核，掩码可直接按物理顺序写，无需跳核
定位物理核归属，避开超线程争抢
超线程下，两个逻辑核（如 0 和 6）可能共享一个物理核的执行单元。盲目绑定 0 和 1，反而造成资源争抢。
查法：lscpu | grep "Core(s) per socket" 得到每路物理核数，再结合 NUMA node(s) 和 CPU(s) per socket 推断配对关系。更直接的是：
- 看
lscpu输出中 “CPU topology” 小节（如有），或 - 运行：
cat /sys/devices/system/cpu/cpu*/topology/core_id 2>/dev/null | sort -u | head -n 4，列出前几个物理核 ID - 再查对应逻辑核：
grep -l "0$" /sys/devices/system/cpu/cpu*/topology/core_id | xargs -I{} basename {} | sed 's/cpu//' | sort -n→ 得到所有归属物理核 0 的逻辑 CPU 编号（如 0 和 6）
结论：若要独占物理核，掩码中同一物理核的多个逻辑核位不能同时为 1；例如物理核 0 对应逻辑核 0 和 6，则 00000001（第 0 位为 1）和 01000000（第 6 位为 1）可分别用于两个 worker，但 01000001 表示两个 worker 都能跑在 0 或 6 上，失去独占意义。
按位序写出标准掩码组
规则只有一条：最右一位（LSB）对应逻辑 CPU 0，向左依次为 1、2……。所以：
- 12 核机器（逻辑核 0–11），掩码每组 12 位，从右往左：位 0 → core 0，位 1 → core 1，……位 11 → core 11
- 设
worker_processes 4，需 4 组掩码，分别绑定到 core 0/1/2/3 → 写成：worker_cpu_affinity 000000000001 000000000010 000000000100 000000001000 - 更稳妥写法（十六进制）：
0001 0002 0004 0008（每组 4 位十六进制 = 16 位二进制，但只要总位宽匹配逻辑核数即可；Nginx 支持自动补零） - 若只想用 NUMA node 0 的逻辑核（如 0–5），且共 12 核，则掩码组可写为：
0000000000111111（后 6 位为 1），但注意这只能启动 1 个 worker；多个 worker 需拆成多组，如0000000000000001 0000000000000010 …
验证是否真正生效
改完配置重启 Nginx 后，不验证等于没配：
- 查每个 worker 当前运行在哪颗 CPU：
ps -eo pid,args,psr | grep 'nginx: worker'→ 看psr列是否互不重复，且落在预期编号内 - 查某 worker 实际亲和掩码：
taskset -cp $(pgrep -f "nginx: worker" | head -1)→ 输出应为类似pid's current affinity list: 0 - 查内核级允许列表：
grep -i cpus_allowed_list /proc/$(pgrep -f "nginx: worker" | head -1)/status→ 值应为单个数字（如0），表示严格绑定
