worker_processes 不支持动态增减，也不用于性能预热；其合理取值（如auto或按cgroup限制显式指定）是扩缩容基础，预热关键在于worker启动后通过keepalive、open_file_cache、ssl_session_cache等机制快速加载资源与连接，并结合编排层init容器或探测实现非阻塞预热闭环。

worker_processes 本身不支持运行时动态增减，也不能用于“性能预热”——它决定的是 Nginx 启动时 fork 出多少个独立工作进程，属于静态部署期配置。所谓“动态扩缩容场景下的预热”，实际要解决的不是改 worker_processes，而是让新启动的 worker 进程快速进入高可用状态，避免冷启动延迟。核心思路是：进程数量固定（或按需重启），但每个 worker 要提前加载资源、绑定资源、建立连接。

以下从三个关键维度给出可落地的配置与实践方案：

✅ 明确 worker_processes 的合理取值，为扩缩容打基础

它不是预热手段，但错误设置会让后续所有优化失效：

• 优先设为 auto：Nginx 自动读取当前环境逻辑 CPU 核数（含容器 cgroup 限制后的核数，2026 年主流版本已支持）
• 容器环境必须显式指定：若 Kubernetes 中限制了 resources.limits.cpu: "2"，则写 worker_processes 2;，避免 auto 误读宿主机核数
• 绝不盲目调大：8 核机器设为 16 个 worker，反而因上下文切换和惊群效应降低吞吐，实测 QPS 可能下降 5%～15%

✅ 利用 on_worker_boot 类机制（需配合上游服务）实现真正“预热”

Nginx 本身无 on_worker_boot 回调，但可通过组合策略达成等效效果：

• 反向代理场景：在 upstream 块中启用 keepalive，并在 reload 后主动发起探测请求（如用 curl -s http://127.0.0.1/healthz 触发连接池初始化）
• 静态文件服务：启用 open_file_cache + open_file_cache_valid，让 worker 在启动后自动缓存热点文件句柄，无需等待首个请求
• SSL 场景：配置 ssl_session_cache shared:SSL:10m; ssl_session_timeout 4h;，使新 worker 复用已有会话缓存，跳过完整 TLS 握手开销

示例：Nginx reload 后，用 systemd timer 或 init 容器触发一次轻量探测

curl -I --connect-timeout 1 http://localhost/nginx_status 2>/dev/null || true

✅ 配合系统层与编排层实现“感知式扩缩容+预热闭环”

当业务负载变化需扩容时，真正的弹性不在单个 Nginx 实例内，而在集群调度层：

• K8s 环境：用 HPA 基于 nginx-ingress-controller 的 nginx_process_resident_memory_bytes 或自定义指标（如 Active connections）触发副本数伸缩；新 Pod 启动时，通过 initContainer 预热 upstream 服务（如 redis-cli ping、mysql -h db -e "SELECT 1"）
• Docker Compose / VM 环境：使用 30-tune-worker-processes.sh 类脚本（检测 CPU_COUNT 或 cgroups/cpu.max）动态生成配置，并在 ENTRYPOINT 中执行预热脚本（如建立数据库连接池、加载 Lua 模块、预热 SSL 会话）
• 关键保障：所有预热操作必须是非阻塞、有超时、可重试的，失败不中断主进程启动

Nginx 的 worker_processes 是地基，不是弹簧。动态扩缩容下的“预热”，本质是让每个新 worker 一出生就带着热数据、连着活连接、跑在对的核上——而不是指望它边干活边学走路。