max_wait_time 是 worker 进程优雅退出的倒计时窗口（默认3秒），仅在 enable_coroutine=true 且 reload_async=true 时生效，超时未退出则被强制终止；它不控制请求接入或并发，需配合 onWorkerStop 完成资源清理，配置错误、环境不匹配或未配对使用 reload_async 均会导致失效。
max_wait_time 控制 worker 进程优雅退出的等待窗口
它不是连接池的“排队超时”，也不是请求处理超时，而是当 worker 进程收到停止信号（比如 reload 或达到 max_request）后，系统允许它继续完成手头任务的最长时间（单位：秒）。超过这个时间还没退出，底层会强制终止。
- 默认值是
3秒，适用于大多数轻量业务；若你的协程中常有长耗时 I/O（如大文件上传、远程 API 调用），可适当调大，但不建议超过30 - 该配置只在
enable_coroutine => true且使用reload_async => true时才真正生效；FPM 模式下完全无效 - 它和
onWorkerStop回调强绑定：所有清理逻辑（如关闭数据库连接、释放资源）必须在这个时间窗内完成，否则会被中断
为什么改了 max_wait_time 却没效果？
常见失效场景不是参数写错，而是运行环境或加载时机不匹配：
- 在 FPM 下修改
max_wait_time—— Swoole 的进程模型根本不启动，这个值压根不会被读取 - 用了
think-swoole扩展但没开启协程：'enable_coroutine' => false，此时max_wait_time不参与任何生命周期管理 - 配置写在
database.php或server.php里，而实际应放在config/swoole.php的server.set数组中，例如：'max_wait_time' => 10 - 代码中在
onWorkerStart之后才创建协程或注册定时器，导致退出时这些异步任务未被感知，max_wait_time到期后直接 kill
max_wait_time 和 reload_async 必须配对使用
单独设 max_wait_time 不会触发优雅重启；它只是“倒计时器”，真正决定是否启用新旧 worker 并行过渡的是 reload_async：
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
-
reload_async => false（默认）：收到reload信号后，worker 立即停止接收新请求，已排队任务可能被丢弃，max_wait_time不起作用 -
reload_async => true：master 启动新 worker，旧 worker 进入max_wait_time倒计时，在此期间仍可处理完正在执行的协程，完成后自动退出 - 注意：如果旧 worker 在
max_wait_time内始终无法退出（比如卡在阻塞 I/O 或死循环），Swoole 底层会强制kill -9，不保证数据一致性
别把它当成防雪崩或限流手段
把 max_wait_time 从 3 改成 60 并不能缓解高并发压力，反而会让失败更隐蔽、资源释放更慢：
- 它不控制请求接入速率，也不限制并发连接数；真正的雪崩防护靠
max_connection、熔断器或上游网关限流 - 过长的
max_wait_time会拖慢 reload 效率，尤其在灰度发布时，旧版本 worker 持续占用内存和 FD，容易触发Too many open files - 真正要防“卡死”，得检查协程内是否有未加超时的
Swoole\Coroutine::sleep()、Co\Http\Client请求，或未关闭的MySQL连接
最容易被忽略的一点：这个值不是越长越安全。它本质是“止损倒计时”，设定依据是你最长单次业务协程的合理耗时上限，而不是拍脑袋填个大数。
