worker_cpu_affinity auto是当前最可靠方式，自动按物理核顺序分配、避开超线程争抢与NUMA跨节点问题，需先用lscpu确认真实CPU拓扑再启用。
直接用 worker_cpu_affinity auto 是当前最可靠的方式，尤其在网关层承担 HTTPS 反代、高频缓存分发的场景下。它自动跳过超线程逻辑核，按物理核顺序分配，避免手动配错掩码导致 Worker 挤在同一核心或跨 NUMA 节点，真正把硬件指令集和缓存局部性优势用足。
先确认物理拓扑，再决定是否启用 auto
网关性能瓶颈常不在计算本身，而在缓存元数据访问延迟与 TLB 刷新抖动。必须明确服务器真实 CPU 架构：
- 运行 lscpu | grep -E "(CPU\(s\)|Core|Socket|NUMA)" 查清物理核数、是否开启超线程、NUMA 节点分布
- 若为双路 CPU（如 2×16 核）且启用 NUMA，不建议用 auto，应显式限定单节点内核，例如只绑 node0 的前 8 核：worker_cpu_affinity auto 000000ff;
- 若为单路 8 核 + HT（共 16 逻辑 CPU），auto 默认只用前 8 个物理核，天然避开超线程争抢，可直接采用
绑定只是起点，缓存热数据必须“留得住”
CPU 绑定让 worker 固定在某核运行，但若共享内存区（如 keys_zone）跨 NUMA 节点、或大小不合理，L3 缓存仍无法高效服务缓存索引查询：
- proxy_cache_path 的 keys_zone 大小按预期 key 数 × 300 字节估算，512m 是常见安全值；过大易碎片，过小触发频繁 LRU 清退
- 加 use_temp_path=off，防止响应体先写临时文件再 move，消除额外 IO 和 inode 锁竞争
- 启用 open_file_cache max=65535 inactive=60s，减少 stat() 系统调用，对大量小缓存对象（如图标、JS 片段）效果显著
配合指令集与内存访问模式做微调
现代 CPU（如 Intel Ice Lake / AMD Zen4）对缓存行对齐、预取行为更敏感，需同步调整 Nginx 内存使用习惯：
- 确保 worker_processes 等于物理核数（非逻辑核），避免多 worker 争抢同一 L2 缓存域
- 关闭未启用模块（如 perl、xslt、geoip2），减小 worker 进程常驻内存 footprint，腾出更多 L3 缓存给 proxy_cache slab 和哈希表
- 若启用 Brotli 或 OpenSSL 3.0+，确认已编译支持 AVX2/SHA-NI 指令，相关压缩/验签操作会自动加速，降低单请求 CPU 占用，间接提升缓存吞吐密度
验证是否真正在“压榨”而非“假绑定”
reload 配置后不能只看 nginx -t 或日志，要实测调度行为与缓存路径表现：
- 执行 ps -eo pid,args,psr | grep 'nginx: worker'，检查每个 worker PID 对应的 PSR 是否稳定落在不同物理核编号上，且不重复
- 用 pidstat -t -p $(pgrep nginx) 1 观察各 worker 线程的 %usr 和 %sys 分布，若某核持续高 %sys（>15%），可能 open_file_cache 或共享内存锁存在争用
- 统计 $upstream_cache_status 中 HIT 与 EXPIRED 比例变化，注意：命中率上升 ≠ 性能提升，还需结合 p99 延迟下降幅度判断是否真正释放了缓存潜力
