swoole timer通过事件循环调度，底层利用epoll_wait/kqueue超时参数，结合最小堆管理定时器，到期后在下一次事件循环tick中串行触发回调。
Timer 是怎么被调度起来的
Swoole 的 Timer 不是靠 PHP 层的 pcntl_alarm 或 usleep 轮询实现的，而是深度绑定在事件循环（Reactor / EventLoop）中，依赖底层的 epoll_wait（Linux）或 kqueue（macOS）的超时参数。每次事件循环进入等待前，Swoole 会计算所有待触发定时器的最近到期时间，把这个差值传给 epoll_wait 的 timeout 参数。
这意味着：Timer 触发精度受限于事件循环的唤醒频率，且不会额外起线程或进程 —— 所有回调都在主线程（或指定的 worker 进程）中串行执行。
- 如果某个回调耗时过长（比如阻塞 IO、密集计算），会拖慢后续所有 Timer 的触发时机
- 定时器不是“到点就立刻执行”，而是“到点后，下一次事件循环 tick 时检查并触发”
-
swTimer_add底层把定时器插入一个最小堆（swHeap），O(log n) 插入/获取最近到期项
addtimer 和 deltimer 的内存生命周期怎么管
每个 swTimer_node 结构体在 swTimer_add 时 malloc 分配，在触发后或被 swTimer_del 时 free。但关键在于：它**不持有 PHP 回调的引用计数** —— 这是高频出问题的点。
如果你用闭包或对象方法作回调，而该对象在定时器触发前已被销毁（比如协程结束、变量超出作用域），Swoole 仍会尝试调用已释放的 zval，导致 core dump 或 segfault。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- PHP 层调用
Swoole\Timer::after(1000, function () { ... })时，Swoole 会主动对闭包做Z_ADDREF_P，并在触发后或删除时Z_DELREF_P - 但 C 层直接调用
swTimer_add不处理 PHP 回调生命周期，必须由使用者确保回调存活 - 常见误操作：在协程里启动一个 long-running timer，协程退出后没手动
Timer::clearAll()或Timer::del($id)，导致悬垂回调
如何安全地在协程中使用 Timer
协程环境下，Swoole\Timer 的静态方法（tick、after、clear）默认绑定当前协程上下文。但要注意：它们注册的仍是底层 eventloop 的定时器，不是协程 sleep —— 即使在协程里调用，也**不自动随协程取消而取消**。
- 协程退出 ≠ 定时器自动销毁；必须显式调用
Timer::clear($id)或Timer::clearAll() - 想实现“协程退出即停”的语义，得自己封装：在协程开始时记录 timer id，在
defer里清理 - 避免在
go(function () { Timer::tick(100, fn() => {}); });中漏掉清理逻辑 —— 这类 timer 会持续跑，直到进程退出 -
co::sleep()是协程级休眠，不走 eventloop timer 系统，两者机制完全隔离
为什么有时候 addtimer 返回 false 或崩溃
最常见原因是传入了非法参数或环境不匹配：
-
Timer::tick(0, $cb)：间隔为 0 会被拒绝，返回false；Swoole 要求最小间隔 ≥ 1ms - 在非 Reactor/Worker 进程（如 manager 进程、信号回调函数内）调用
Timer::after，底层swTimer_add检查到无可用 timer heap，直接 return false - 在 PHP
__destruct中调用Timer::clearAll()，此时 Swoole 全局结构可能已析构，引发段错误 - 大量高频 timer（如每毫秒一个）未及时清理，导致
swHeap内存碎片或节点数超限（默认上限 10000），新添加失败
真正难调试的是 timer 回调里再调 Timer::tick 形成嵌套调度 —— 表面正常，实则 heap 压力陡增，某次扩容失败就静默失败。
