ngx_cpuinfo指令并不存在于官方Nginx中；它既非内置指令，也非标准或主流第三方模块提供，实为对cpu_affinity、源码内函数（如ngx_cpuid_init）或定制patch的误称。
ngx_cpuinfo 指令本身并不存在于官方 Nginx 源码中 —— Nginx 核心不提供 ngx_cpuinfo 这一配置指令，也没有名为 ngx_cpuinfo 的模块或函数。
为什么找不到 ngx_cpuinfo？
Nginx 官方文档、源码树（包括 src/core/、src/os/unix/）以及所有稳定版本（1.20.x 至 1.25.x）中均无该指令定义。它不属于：
- Nginx 内置指令（如
worker_processes、use、cpu_affinity） - 标准模块（
ngx_http_core_module、ngx_os.h等）的导出接口 - 主流第三方模块（如
nginx-module-vts、headers-more）的公开配置项
可能的混淆来源
用户常将以下内容误称为 ngx_cpuinfo：
cpu_affinity
-
worker_cpu_affinity（旧版命名，1.9.10+ 统一为cpu_affinity） -
源码中用于探测 CPU 特性的内部函数，例如：
•ngx_os_init()中调用的ngx_cpyinfo_init()（实际为ngx_cpuid_init()，用于 x86/x64 的 CPUID 检测）
•src/os/unix/ngx_linux_config.h或ngx_darwin_config.h中的架构宏判断
• 第三方 patch（如某些国产化适配分支）自行添加的调试指令
真正影响 CPU 利用率的核心机制
Nginx 在不同架构下实现 CPU 感知优化，依赖的是隐式逻辑而非显式指令：
-
自动 worker 进程绑定：通过
cpu_affinity auto，Nginx 调用sched_setaffinity()（Linux）、pthread_setaffinity_np()（glibc）或cpuset_setaffinity()（FreeBSD），按物理核/超线程拓扑分配进程 -
架构适配的原子操作：在
src/core/ngx_atomic.h中，根据__x86_64__、__aarch64__、__riscv等宏选择lock xadd、ldxr/stxr、amoswap.w等指令序列 -
CPU 特性运行时检测：x86 平台通过
ngx_cpuid()（封装cpuid指令）识别 SSE4.2、AVX、BMI2 等，决定是否启用ngx_strlow的向量化路径；ARM64 则读取ID_AA64ISAR0_EL1寄存器（需内核支持）
如何在自定义模块中安全获取 CPU 信息？
若需在模块中做架构相关优化，应复用 Nginx 已有设施：
- 检查
NGX_HAVE_CPU_AFFINITY宏判断系统是否支持绑核 - 读取
ngx_ncpu（OS 初始化后填充的逻辑 CPU 数） - 使用
ngx_sched_setaffinity(cycle->cpu_affinity)手动设置当前进程掩码 - 对 aarch64，可调用
getauxval(AT_HWCAP)检查HWCAP_ASIMD、HWCAP_AES等标志
不复杂但容易忽略：Nginx 的 CPU 优化是“静默发生”的 —— 它没有炫技式的 ngx_cpuinfo on 开关，而是把探测、适配、调度全埋在初始化流程与原子操作封装里。想深入，直接看 ngx_os_init() 和 ngx_set_cpu_affinity() 的实现比找一个不存在的指令更有价值。
