swoole 4+ 协程中信号只能在主线程注册并同步执行回调，不可在协程或子进程中调用signal()；回调内禁止协程操作，应仅设标志或发消息，复杂逻辑交由主协程异步处理。
在 Swoole 4+ 协程环境中，信号不能直接在任意协程中捕获或处理。信号注册和回调执行有明确的线程与调度约束——所有信号处理器必须在主线程（即主进程的事件循环线程）中注册，且回调函数只能在主线程同步执行，不可进入协程调度上下文。
信号注册必须在主线程完成
Swoole 使用 Swoole\Process::signal() 注册信号，该调用仅在主线程有效。若在子进程、Worker 进程或某个协程中调用，会静默失败或触发警告（如 Warning: signal(): Not supported in coroutine environment）。尤其注意：
– onStart 回调中可安全注册（此时仍在 Manager 或 Worker-0 的主线程）；
– onWorkerStart 中注册可能失效（取决于进程模型与版本，v4.8+ base 模式下 Worker-0 才具备主线程能力）；
– go() 启动的协程内调用 signal() 会直接报错。
信号回调函数必须非阻塞且无协程切换
操作系统投递信号时，Swoole 将其转为同步回调，在事件循环主线程中立即执行。因此回调内：
– 禁止调用 co::sleep、mysql->query、http->get 等任何会触发协程挂起的操作；
– 不可使用 go()、Channel->push()（除非是无锁、无调度的底层 Channel）；
– 推荐只做轻量操作：设置标志位、写入管道、调用 $server->shutdown() 等已封装好的非阻塞方法；
– 若需复杂清理逻辑（如等待数据库事务结束），应通过 Channel 或 Atomic 通知主协程异步执行，而非在信号回调里硬编码。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
协程内无法“监听”信号，需靠主线程中转
协程本身没有信号监听能力。常见安全模式是：
– 主线程注册 SIGTERM，回调中向预创建的 Channel 发送 shutdown 指令；
– 主协程（如 go(function(){...})）持续 $chan->pop() 监听，收到后执行优雅关闭流程；
– 避免在协程里轮询 pcntl_signal_dispatch() 或依赖 pcntl_async_signals(true)，这些在协程环境下不可靠且易引发竞态。
典型错误与规避方式
错误写法：
– 在 onRequest 回调里调用 Swoole\Process::signal(SIGUSR1, ...)；
– 信号回调中执行 Redis::set(...) 或 Co::exec('ls')；
– 用 sleep(1) 替代 Co::sleep(1) 以为能延时——实际会阻塞整个事件循环。
正确做法：
– 信号注册统一放在 onStart 或 Server 实例化后、start() 前；
– 回调只写 $shutdownFlag = true; 或 $chan->push('exit');；
– 清理任务交给独立协程，配合 Co::waitGroup 或超时 Channel::pop(5) 控制生命周期。
