worker_processes auto在容器中是按规则探测而非智能适配，依赖/proc/cpuinfo或cgroups限额，不感知CPU配额限制；未配合资源约束易致CPU争抢、上下文切换激增或OOMKilled。

worker_processes auto 在容器中不是“智能适配”，而是“按规则探测”：它读取 /proc/cpuinfo 或 cgroups 限额，但不会主动感知容器的 CPU 配额限制。若不配合容器资源约束，极易启动过多 worker，引发 CPU 争抢、上下文切换激增，甚至被 OOMKilled。

确认容器真实可用 CPU 数量

auto 的行为取决于底层 cgroups 限制，而非宿主机核数：

• 必须在启动容器时显式设置 CPU 限制，例如：docker run --cpus=2 或 Kubernetes 中配置 resources.limits.cpu: "2"
• Nginx ≥1.19.0 才支持从 cgroups v1/v2 自动读取（推荐 ≥1.21.0）；旧版本仍会读宿主机 /proc/cpuinfo，导致误判
• 运行环境需为 Linux 主机（Windows/macOS Docker Desktop 的模拟 CPU 不被识别）
• 基础镜像内核建议 ≥5.4，确保 cgroups v2 支持稳定

验证 auto 是否按预期生效

进入容器后逐条执行，交叉比对结果：

• nginx -t -v：确认 Nginx 版本 ≥1.19.0
• cat /sys/fs/cgroup/cpu.max 2>/dev/null || cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us：查看实际 cgroups 限额（如 200000 表示 2 核配额）
• nginx -T 2>/dev/null | grep "worker_processes"：检查最终解析值（注意 -T 输出的是合并后生效配置）
• ps aux | grep nginx | grep -v grep：统计运行中的 worker 进程数，应与 cgroups 限额匹配

容器环境更稳妥的写法

不完全依赖 auto，采用“显式声明 + 启动时注入”组合策略：

• 主配置中保留 worker_processes auto;（作为 fallback）
• 在 entrypoint 脚本或 initContainer 中动态生成覆盖配置：
  echo "worker_processes $(getconf _NPROCESSORS_ONLN);" > /etc/nginx/conf.d/worker.conf
• 搭配 worker_cpu_affinity auto;（Linux only），让每个 worker 绑定独立 CPU；若仅分配 1 核，该指令自动禁用，避免无效配置
• 同步收紧连接限制：events { worker_connections 2048; }，防止高并发下文件句柄耗尽

静态分发场景的轻量化加固

纯前端托管、CDN 边缘等静态服务，应在进程数合理基础上进一步降低开销：

• 启用零拷贝加速：sendfile on; tcp_nopush on;
• 静态资源强制长期缓存：location ~* \.(js|css|png|jpg|gif|ico|svg|woff2?)$ { expires 1y; add_header Cache-Control "public, immutable"; }
• 关闭访问日志：access_log off;，或改用异步日志模块减少 I/O 阻塞
• 编译时裁剪非必要模块（如 --without-http_rewrite_module），减小内存 footprint