应执行nproc命令查真实可用逻辑CPU数，因其在容器/K8s中准确返回cgroup限制的vCPU数；输出为4则设worker_processes 4，不可依赖phpEnv面板或lscpu宿主机数据。
phpEnv 本身不控制 Nginx 的 worker_processes，它只是个集成环境套件；真正起作用的是你手动编辑的 nginx.conf —— 优化必须落到这个文件里，否则改 phpEnv 界面或脚本毫无意义。
怎么查当前服务器真实可用的 CPU 核心数
phpEnv 安装的 Nginx 运行在宿主机（或容器）上，worker_processes 必须匹配实际分配的逻辑 CPU 数，不是看 phpEnv 面板、也不是看宿主机总核数。
- 登录服务器终端，执行
nproc—— 这是最准的，尤其在容器/K8s 中，它返回 cgroup 实际允许的 vCPU 数 - 若输出是
4，就设worker_processes 4;；输出是2，就设2，别被 phpEnv 自带的“推荐配置”误导 - 避免用
lscpu | grep "CPU(s):"，它可能显示宿主机全部逻辑核，而 phpEnv 实例根本分不到那么多 - 确认 phpEnv 启动的 Nginx 是以哪个用户运行（通常是
www或nginx），后续ulimit限制要对齐该用户
phpEnv 环境下必须改的 nginx.conf 位置和写法
phpEnv 默认把 Nginx 配置放在 /usr/local/phpenv/nginx/conf/nginx.conf（路径可能因版本略有差异，可用 find /usr/local/phpenv -name nginx.conf 确认）。修改时注意：
-
worker_processes必须放在main块（即文件最顶部、events { ... }之前），不能塞进http或server块里，否则 Nginx 启动直接报错 - 优先用
worker_processes auto;—— phpEnv 没做任何拦截，Nginx 1.3.8+ 完全支持，且会正确读取nproc结果 - 如果 phpEnv 版本老旧（如基于 Nginx 1.8 或更早），
auto不生效，则必须手动写死数字，例如：worker_processes 4; - 改完务必执行
/usr/local/phpenv/nginx/sbin/nginx -t校验语法，再用/usr/local/phpenv/nginx/sbin/nginx -s reload生效
为什么开了 worker_cpu_affinity 还没效果
在 phpEnv 环境中，即使配了 worker_cpu_affinity，也常因两个原因失效：
立即学习“PHP免费学习笔记（深入）”；
-
worker_processes和worker_cpu_affinity的数量不匹配：比如写了worker_processes 4;，但worker_cpu_affinity只给了三个掩码（如0001 0010 0100），Nginx 启动失败；必须严格一一对应，缺一不可 - phpEnv 启动脚本绕过了配置加载：有些定制版 phpEnv 会用自定义 shell 脚本启动 Nginx，并强制覆盖
-c参数指向另一个配置文件，此时改nginx.conf白忙——应检查/usr/local/phpenv/init.d/nginx或 systemd service 文件里的启动命令 - 验证是否真绑上了：执行
ps axo pid,comm,psr | grep nginx | grep -v master，第三列（PSR）应是你期望的 CPU ID；若全是 0，说明 affinity 没生效或被调度器覆盖
最易被忽略的是：phpEnv 默认不会帮你调系统级 ulimit。即使 worker_processes 设对了，每个 worker 默认只有 1024 个文件描述符，高并发下会快速打满并报 accept() failed (24: Too many open files)。必须同步改 /etc/security/limits.conf，加两行：www soft nofile 65535 和 www hard nofile 65535（把 www 换成你环境中 Nginx 实际运行的用户名），然后重新登录终端或重启 phpEnv 服务才能生效。
