reload_async=true使热重启不阻塞新请求，新worker提前接管流量，旧worker完成异步任务后优雅退出；需Swoole≥4.8.13、禁用daemonize或配systemd ReloadSignal，且worker中不可有阻塞调用。
reload_async=true 是为了让 reload 不阻塞新请求
这个配置项控制的是热重启过程中，新连接能否继续被接受。设为 true 后，主进程收到 SIGUSR1 或 SIGHUP 信号触发 reload 时，不会等待所有 worker 进程退出完才开始处理新请求；而是让新的 worker 进程提前启动、接管流量，旧的 worker 在完成手头异步任务（如协程中的 I/O、task 投递、onClose 回调）后再优雅退出。
- 必须搭配 Swoole ≥ 4.8.13 使用，低版本存在竞态 bug，
reload_async可能静默失效 - 若启用了
daemonize => true，主进程会脱离终端，SIGUSR1信号可能无法送达——此时需用 systemd 管理，并配置ReloadSignal=SIGUSR1 - worker 进程里不能有死循环、无超时的阻塞调用（比如没设 timeout 的
curl_exec、卡住的数据库连接池初始化），否则会卡在 “waiting for worker exit” 阶段，整个 reload 就挂住了
为什么 Think-Swoole 默认强制设为 true 却又写死成 false？
Think-Swoole 底层在 InteractsWithServer.php 中硬编码了 'reload_async'=>true，但实际运行时你看到的是 false，是因为它紧接着又覆盖了一次：'reload_async'=>true 被后面显式的 set() 调用覆盖掉了——而该调用里明确写了 'reload_async'=>true 并没被写死，真正被写死的是 max_request 和 task_max_request。
所以你看到的 reload_async 实际值，取决于你自己的 config/swoole.php 里怎么配，不是框架“故意锁死”。但要注意：如果用的是 Think-Swoole v4.1.x 之前的老版本，确实存在部分配置被覆盖后不可修改的问题，升级到 v4.1.5+ 更稳妥。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
reload_async 和 max_request 的协作关系容易被忽略
reload_async 解决的是“重启过程是否阻塞”，而 max_request 决定“进程是否自动退出”。两者常一起用，但作用域完全不同：
-
reload_async是主进程级开关，影响信号处理流程 -
max_request是 worker 进程级行为，靠子进程自己计数并退出，不依赖主进程发信号 - 如果你只设了
max_request却没开reload_async，worker 退出后主进程仍会阻塞等待，直到所有旧 worker 彻底结束，这期间新连接可能被拒绝或排队积压 - 生产环境建议组合使用：
'reload_async'=>true+'max_request'=>3000，既防内存泄漏，又保热更安全
验证 reload_async 是否真生效的最简方法
别只看日志或进程列表，直接观测行为：
- 起一个长连接客户端（比如 WebSocket 连接后不发任何消息），保持连接打开
- 执行
kill -USR1 `cat /var/run/swoole.pid` - 立刻发起新连接（比如 curl 或另一个 ws 客户端），确认能连上且不报错
- 等 2–3 秒后，再检查原长连接是否还在（
netstat -an | grep :9501 | grep ESTAB），如果仍在，说明旧 worker 没被强杀，reload_async生效了
最容易漏掉的一点：很多团队开了 reload_async 却没关 inotify_mode，导致开发期文件监听和生产热更混用，反而引发 CPU 飙升——生产环境务必设 'inotify_mode' => SWOOLE_INOTIFY_NONE。
