reload是平滑重载，主进程pid不变、新旧worker并存、不中断连接；restart是彻底重启，主进程被终止重建、pid变更、所有连接中断。
平滑重载（reload）和“平滑重启”在 Nginx 中其实是同一机制的两种常见误称——官方只有 reload，没有 restart。所谓“平滑重启”，本质上就是 reload；而真正意义上的“重启”（即 stop + start）会中断连接，不属于平滑操作。验证两者区别，关键不在命令名，而在进程行为、连接状态与信号路径这三个边界。
看主进程是否被替换
这是最核心的区分点：
- nginx -s reload 或 systemctl reload nginx：仅新启 worker 进程，主进程 PID 不变；旧 worker 逐步退出，新 worker 接管新连接
- systemctl restart nginx 或 nginx -s stop && nginx：主进程被终止并重新 fork，PID 变更；所有 worker 进程被强制杀掉，服务短暂不可用
看活跃连接是否被中断
可通过真实请求+长连接观察：
- 执行 reload 后，用 curl -H "Connection: keep-alive" 发起一个持续 30 秒的请求（如 sleep 30 的后端），该连接仍能完成，且不报错
- 执行 restart 后，同样请求大概率在 1–2 秒内断开，返回 connection reset 或 empty reply
- 也可用 ss -tnp | grep :80 观察 reload 前后是否有连接始终保留在旧 worker 的 fd 上（需配合日志或自定义 log_format 记录 $pid）
看信号触发路径是否绕过主进程校验
reload 是受控流程，restart 是暴力流程：
- reload 实际等价于向主进程发 SIGHUP，主进程会先隐式执行 nginx -t，失败则拒绝变更，旧配置继续运行
- restart 绕过语法检查：systemctl restart nginx 直接调用 ExecStop= 和 ExecStart=，即使配置有错，也会强行启动失败（报 failed to start），但此时旧服务已消失
- 手动 kill -HUP $(cat /var/run/nginx.pid) 和 nginx -s reload 行为一致；而 kill -TERM $(cat ...) + 手动启动，则属于非平滑重启
看日志与进程树变化节奏
reload 有明确的“双 worker 共存期”，restart 是“清零再建”：
- reload 后立即执行 ps aux | grep nginx，可见主进程 PID 不变，同时存在新旧 worker（例如 5 个旧 + 5 个新），数秒后旧 worker 自然消失
- restart 后 ps 输出中旧进程全无，新主进程 PID 变化，worker 是一次性全新创建
- 查看 error.log：reload 会记录 “reloading configuration”；restart 则出现 “exiting” → “starting” 两段日志，中间可能夹杂 bind() 失败或 open() 日志文件失败等启动期错误
