swoole_reload() 无反应主因是仅重载工作进程中的动态PHP代码，对主进程、全局变量、内核配置无效；需清opcache、确保信号权限正确、避免协程中直接调用，并手动重置单例等资源。
为什么 swoole_reload() 没反应？
多数时候不是函数没调用，而是它根本没被触发——swoole_reload() 只对工作进程（worker）里的 PHP 代码生效，对主进程（master）、管理进程（manager）或常驻内存的全局变量无效。你改了 onWorkerStart 里的初始化逻辑，或者动了 global $config 这类顶层变量，reload 后照样还是旧值。
常见错误现象：swoole_reload() 返回 true，但新请求仍走老逻辑；日志里看不到 reload 触发后的重新加载痕迹；改了路由或回调函数，请求结果完全没变。
- 只重载 worker 进程中通过
require/include加载的业务文件（需确保是运行时动态加载，而非启动时一次性require_once） - 不能重载 Swoole 内核配置（如
worker_num、daemonize），这类必须停服重启 - 若使用了 opcache，得先清掉缓存（
opcache_reset()），否则即使 reload 了，PHP 还在跑编译后的旧 opcode
用 kill -USR1 重载却报错 Operation not permitted
这是 Linux 权限问题，不是 Swoole bug。USR1 信号只能由进程所有者或 root 发送，如果你用 www-data 启动服务，但用普通用户执行 kill -USR1，系统直接拒绝。
使用场景：线上环境常用 systemd 或 supervisor 管理进程，它们默认以非 root 用户拉起服务，此时信号转发容易失败。
- 确认当前用户和进程所有者一致：
ps aux | grep php查看 USER 列 - 用
sudo -u www-data kill -USR1 $(cat /path/to/swoole.pid)精准发送（别漏-u） - 如果用 systemd，改用
systemctl reload your-swoole.service，并在 service 文件里配好ReloadSignal=USR1 - 某些容器环境（如 Alpine）默认禁用 USR1，需检查内核参数或换用
kill -SIGUSR1
Server->reload() 在协程模式下失效
协程服务器（SWOOLE_BASE 或 SWOOLE_PROCESS + enable_coroutine=true）里，Server->reload() 会阻塞当前协程，且不保证所有 worker 同时完成重载——部分 worker 可能卡在 I/O 协程里，导致 reload 调用超时返回 false，实际只有部分进程更新了。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
性能影响：频繁调用 Server->reload() 可能引发 worker 进程状态不一致，尤其在高并发长连接场景下，新旧逻辑混跑容易出数据错乱。
- 避免在协程上下文里直接调用
$server->reload()，改用go(function () use ($server) { $server->reload(); })脱离当前协程调度 - 更稳妥的做法是：用
Server->addProcess()启一个独立管理进程，监听文件变更（如 inotify），再统一发信号 - 确认
max_wait_time配置足够长（默认 60s），否则 reload 中途被判定为失败
改完代码，kill -USR2 也重启不了？
USR2 是强制重启信号，但它依赖 Swoole 正常响应信号——如果主进程已卡死、陷入死循环、或被 strace/gdb 暂停，USR2 就发不进去。这时候看到的现象是：kill -USR2 命令没报错，但 ps 里进程 PID 没变，lsof -i :port 显示端口还占着，就是没起来新 worker。
容易踩的坑：以为“发了信号=重启成功”，其实只是信号进了内核队列，Swoole 主循环没轮到处理它。
- 先用
strace -p $(cat swoole.pid) -e trace=signal看信号是否真正抵达进程 - 检查 error_log 是否有
Segmentation fault或Bus error，这类崩溃会让主进程无法响应后续信号 - 极端情况下，直接
kill -9杀掉再手动php server.php启动，比硬扛信号更可靠 - 别依赖 PID 文件自动读取——有些部署脚本写死了 pid 路径，而实际服务可能把 pid 写到了别的位置（比如
/tmp/swoole.pidvs/var/run/swoole.pid）
真正麻烦的从来不是怎么发信号，而是 reload 后谁在用旧的闭包、旧的单例、旧的数据库连接池——这些不会随进程重启自动清理，得靠你自己在 onWorkerStart 或 onWorkerStop 里显式重置。
