nginx -s reload 是信号驱动的多阶段热重载：先校验语法，再并存新旧配置结构体致内存翻倍，随后新worker接管、旧worker优雅退出；它不升级版本，仅更新配置。
nginx -s reload 是 Nginx 实现配置热更新的核心机制，它不中断服务、不丢连接，但也不是“零成本”操作。理解其背后流程，才能避免误用、规避风险、精准调优。
reload 的本质是信号驱动的多阶段交接
执行 nginx -s reload 等价于向主进程（master）发送 HUP 信号，触发以下不可跳过的步骤：
- 主进程先隐式执行 nginx -t，校验新配置语法；失败则中止，旧配置继续运行
- 语法通过后，主进程完整解析新配置，构建一套全新的内存结构（含监听套接字、缓存区、模块上下文等）——此时新旧两套结构体并存
- 主进程 fork 出新 worker 进程，新进程加载新结构体，开始 accept 新连接
- 旧 worker 进程收到 QUIT 信号，停止 accept 新连接，只处理已建立的请求
- 旧 worker 完成所有现存请求后退出，主进程释放旧配置结构体，内存逐步回落
为什么 reload 后内存会短暂翻倍？
这不是 bug，而是设计使然。关键在于“新旧结构体并存”这一中间状态：
- proxy_cache 或 fastcgi_cache 启用/扩容时，新旧 worker 可能各自持有缓存元数据和内存块
- 增大 client_max_body_size 或 large_client_header_buffers，每个新 worker 启动即预分配更大缓冲区
- 加载大型第三方模块（如 subs_filter 处理大响应体），若内部未调用 malloc_trim，堆内存不会立即归还系统
- 大量 server 块或深层 location 嵌套，导致配置树解析与存储开销显著上升
reload 并非对所有连接都“无感”
是否真正平滑，取决于你是否显式控制了长连接生命周期：
- worker_shutdown_timeout 是决定成败的关键参数：它定义旧 worker 收到 QUIT 后最多还能服务多久
- REST 接口建议设为 10–30 秒；WebSocket 至少 125 秒；大文件上传需 ≥450 秒
- 该值过短，会导致上传中断、心跳断连、支付回调丢失；过长则堆积空闲连接，耗尽 fd 和端口资源
- 它仅在标准 reload 流程中生效；kill -9 或 systemctl restart 会完全绕过此逻辑
reload ≠ 版本升级，别混淆这两个概念
很多人误以为执行一次 reload 就完成了 Nginx 升级，这是危险认知：
- HUP 信号只重载配置，所有新 worker 仍运行在**当前二进制文件**上，nginx -v 输出不会变
- 真正的零停机版本升级，必须使用 USR2 + WINCH + QUIT 三步信号组合，实现新旧二进制共存与平滑交接
- 若仅靠 reload 就上线了安全补丁或新特性，实际漏洞仍在、功能未启用
