max_wait_time是旧worker优雅退出的兜底超时阈值，非宽限期；仅当reload_async=true时生效，超时未退出则被sigkill强制终止，需大于业务最长请求耗时且与nginx超时对齐。
max_wait_time 不是“等待多久就停”，而是“最多等多久才强制杀”
很多人误以为 max_wait_time 是给 Worker 进程留出的“宽限期”，超时后自动优雅退出。实际不是：它只是个安全兜底阈值，一旦旧 Worker 在该时间内没自行结束，主进程会发 SIGKILL 强制终止——此时正在执行的协程、未完成的异步 I/O、未返回的 task 结果都会丢失。
这个值必须大于你业务中最长单次请求耗时（含下游超时），否则可能打断正常请求；但也不能设得过大，否则重启卡住，影响发布节奏。
- HTTP 场景建议设为
10～30秒，配合 Nginx 的proxy_read_timeout对齐 - 定时任务（Crontab）或队列消费者场景，需考虑最长任务执行时间，比如一个导出任务跑 5 分钟，
max_wait_time至少设为300 - Hyperf 项目中若启用了
reload_async => true，max_wait_time才真正生效；否则即使设了也走立即终止逻辑
不配 reload_async 时，max_wait_time 形同虚设
reload_async 决定了整个平滑重启机制是否启动。如果它是 false（默认值），Swoole 收到 SIGUSR1 后直接终止 Worker，max_wait_time 完全不参与流程——旧进程里所有未完成的协程、go 启动的任务、defer 注册的清理逻辑，全部被丢弃。
只有在 reload_async => true 下，Swoole 才会：先 fork 新 Worker，再通知旧 Worker 进入“拒绝新请求 + 等待存量任务结束”状态，并启用 max_wait_time 倒计时。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- Hyperf 的
server.php中需显式配置：'reload_async' => true - 原生 Swoole 启动前调用
$server->set()时必须包含该键 - 检查是否生效：重启后观察日志里是否有
worker exit gracefully类提示，而不是直接worker exit
max_wait_time 和 max_request 共同决定 Worker 生命周期
max_request 控制每个 Worker 处理多少请求后主动退出（防内存泄漏），而 max_wait_time 控制它退出时能拖多久。两者常一起出现，但作用阶段不同：
-
max_request触发的是“主动退出流程”，此时同样会尊重max_wait_time（前提是reload_async开启） - 如果
max_request = 1000，但某 Worker 在第 999 个请求时开始处理一个 60 秒的长任务，且max_wait_time = 30，那它会在 30 秒后被强杀，第 1000 次请求永远无法达到 - 生产环境建议把
max_request设高些（如5000），靠max_wait_time和信号控制更可控的重启时机
验证 max_wait_time 是否真起作用，别只看进程 PID 变了
光看 ps aux | grep php 发现 Worker PID 刷新了，不代表平滑——可能只是暴力重启。真正验证得看行为：
- 在请求入口加日志：
echo "start: " . microtime(true) . " pid:" . getmypid() . PHP_EOL;，然后发起一个长 sleep 请求（如usleep(2000000)） - 发
kill -USR1 $master_pid，观察该请求是否完整返回（而非 502 或中断） - 查错误日志里有没有
coroutine was destroyed或task timeout类报错 - Hyperf 用户可监听
OnWorkerStop事件，在里面打点记录退出时间，对比max_wait_time是否被遵守
最容易被忽略的是：开发时本地测试往往请求极短，max_wait_time 看似“总能等完”，一上生产遇到慢查询或外部依赖超时，立刻暴露问题。
