Swoole中信号处理不能用pcntl_signal()，必须用Swoole\Process::signal()或swoole_signal()；定时器必须用Swoole\Timer::tick()或Swoole\Timer::after()，混用会导致失控。
直接说结论：Swoole 中的信号处理不能靠 pcntl_signal()，定时器必须用 Swoole\Timer::tick() 或 Swoole\Timer::after()，混用系统信号 + PHP 原生定时器会彻底失控。
为什么 pcntl_signal 在 Swoole 里基本失效
Swoole 的 Master 进程自己接管了全部信号（SIGTERM、SIGUSR1 等），Worker 进程默认屏蔽所有信号；即使你在 onWorkerStart 里调用 pcntl_signal()，也大概率被 Swoole 内部重置或忽略。
- Master 进程只响应预设信号：比如
SIGTERM触发平滑重启，SIGUSR2触发 reload 配置 —— 这些行为无法覆盖或拦截 - Worker 进程若强行启用
pcntl_signal_dispatch()，会干扰 Reactor 事件循环，导致连接卡死、定时器延迟甚至崩溃 - 真正需要自定义信号响应的场景（如热加载配置），应改用进程间通信：
Server->sendMessage()向指定 Worker 发送数据，再在onPipeMessage回调里处理
Timer::tick 和 Timer::after 的关键区别
两者底层共用同一套红黑树定时器，但生命周期和触发逻辑完全不同，选错会导致内存泄漏或任务漏执行。
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
-
Timer::tick(1000, function () { ... })返回一个整数 ID，该定时器持续运行，直到显式调用Swoole\Timer::clear($id) -
Timer::after(5000, function () { ... })是一次性任务，执行完自动销毁，不返回 ID，也无法清除 - 协程环境下慎用
tick()：回调函数内若发生未捕获异常，定时器不会自动停，但后续调用会失败（Swoole\Timer::clear()仍有效） - 高频 tick（如 Co::sleep() + 循环替代，更可控
onWorkerStart / onWorkerStop 里启动/清理定时器的坑
很多人以为在 onWorkerStart 启动定时器就能“每个 Worker 独立跑一个”，但实际容易重复创建、ID 冲突、清理遗漏。
- 定时器 ID 全局唯一，不是 Worker 级别隔离的 —— 多个 Worker 同时调用
tick()可能返回相同 ID（极小概率），导致clear()清错任务 -
onWorkerStop不一定总被触发：Worker 被强制 kill、OOM 或 segfault 时，该回调完全不执行，依赖它清理定时器等于裸奔 - 安全做法：把定时器 ID 存到 Worker 局部变量（如
$worker_timer_id），并在onWorkerStart先检查是否已存在，再创建；同时设置'max_request' => 2000强制 Worker 退出，兜底回收
信号 + 定时器组合场景下的真实风险点
比如“收到 SIGUSR1 后暂停定时任务，30 秒后自动恢复”——这种需求看似合理，实则暗藏三重陷阱。
- Swoole 不允许在信号回调（如
onManagerStart里注册的pcntl_signal）中调用任何 Swoole API，包括Timer::clear()，会直接 core dump - Worker 进程收不到
SIGUSR1（除非显式pcntl_sigprocmask解除屏蔽，但破坏 Swoole 运行模型） - 真正可行路径只有：Master 进程监听信号 → 通过
Server->sendMessage()推送指令 → Worker 在onPipeMessage里调用Timer::clear()或Timer::tick()，且必须加锁防并发修改同一 ID
最常被忽略的是：定时器回调函数里的资源句柄（如 Co\Redis 实例）没有生命周期绑定，Worker 重启时若没手动 close，连接池会被污染，后续请求可能复用到已断开的连接。
