应以物理CPU核心数设置worker_processes，鲲鹏需ARM64原生编译并启用armv8-a+crypto优化，海光建议znver2优化；须用lscpu确认真实物理核数，容器中禁用auto而显式指定，并配worker_cpu_affinity auto；同步调高文件描述符、固定epoll模型，K8s中需与resources.limits.cpu严格对齐。
在鲲鹏（ARM64）、海光（x86_64 兼容）等国产芯片架构上配置 worker_processes，核心原则不变：**以物理 CPU 核心数为基准，而非逻辑核数或盲目套用 auto**；但需特别注意编译适配、运行时识别和容器环境限制。
必须在原生环境中构建 Nginx
国产芯片不是“换个 CPU 就能跑”，Nginx 必须针对目标架构原生编译：
- 鲲鹏（ARM64）服务器：直接在鲲鹏机器上用
gcc编译，启用--with-cc-opt="-march=armv8-a+crypto"等指令集优化，禁用 x86 专属选项 - 海光（Hygon，兼容 x86_64）：按标准 x86 流程编译，但建议添加
--with-cc-opt="-march=znver2"（对应海光 C86 架构）提升向量化性能 - 禁止跨架构交叉编译后直接部署——即使二进制能启动，也可能因浮点/原子指令不兼容导致偶发崩溃或性能异常
物理核数识别要绕过虚拟化干扰
部分国产云平台（如天翼云信创专区、移动云磐石）使用 KVM 或自研虚拟化，/proc/cpuinfo 可能失真。应以以下方式确认真实物理核数：
- 执行
lscpu | grep -E "Core\(s\) per socket|Socket\(s\)"→ 相乘得物理核总数（例如：2 sockets × 32 cores = 64） - 对比
nproc --all输出：若两者差异大（如物理核 32，逻辑核 64），说明启用了超线程，此时worker_processes起点应为 32，不是 64 - 在国产容器平台（如华为云 CCE Turbo 信创集群）中，
auto可能读取宿主机核数，必须显式覆盖
配置写法：推荐显式指定 + auto 绑核
不依赖 worker_processes auto 的自动探测，尤其在信创环境稳定性优先：
- 物理核数为 32 → 写
worker_processes 32;，并紧随其后加worker_cpu_affinity auto;（要求 Nginx ≥ 1.9.10） -
auto模式在此类多核 ARM/x86 平台表现可靠：它会跳过超线程对称逻辑核（如只用 CPU 0、2、4…），把每个 worker 稳定绑定到不同物理核的第一个硬件线程 - 避免手动写十六进制掩码（如
00000001 00000010 …），国产芯片的 CPU 编号顺序与 x86 可能不同，易出错
信创场景下的关键配套动作
仅调 worker_processes 不足以发挥国产芯片性能：
- 文件描述符必须同步提升：
worker_rlimit_nofile 65535;，并在系统层设置ulimit -n 65535（修改/etc/security/limits.conf） - 事件模型固定为
use epoll;（鲲鹏/海光均基于 Linux 内核，epoll 是最优解） - Kubernetes 中务必与
resources.limits.cpu: "16"严格对齐，写worker_processes 16;，否则可能因 vCPU 配额不足引发 OOM 或调度延迟 - 验证是否生效：重启后运行
ps -eo pid,psr,comm | grep nginx，确认各 worker 的 PSR 列稳定分布在不同编号（如 0、1、2…31），且不跳变
