定时器必须在Worker进程调用，swoole_timer_tick需置于onWorkerStart等Worker上下文；协程环境优先用Swoole\Coroutine\Timer；注意清除ID防泄漏、避免阻塞操作、系统时钟精度影响实际间隔。
定时器没触发？检查 swoole_timer_tick 是否在 Worker 进程中调用
高频定时器（如毫秒级）必须在 Worker 进程里启动，不能在 Master 或 Manager 进程中调用，否则会直接失败或静默丢弃。Swoole 的定时器底层依赖 epoll/kqueue，只有 Worker 进程有事件循环。
-
swoole_timer_tick(10, function() { ... })必须放在onWorkerStart、onReceive或其他 Worker 上下文回调里 - 在
onStart里调用只会返回false，且不报错——这是最常踩的坑 - 协程环境下别混用：
Swoole\Timer::tick()是同步阻塞式接口，而co::sleep()+ 循环不是真定时器，会漂移
10ms 定时器卡顿？确认系统时钟精度和 CPU 负载
Linux 默认 CLOCK_MONOTONIC 精度约 1–15ms，低于 10ms 的 swoole_timer_tick 实际间隔可能拉长，尤其在高负载或虚拟机中。
- 用
cat /proc/sys/kernel/timer_freq查看内核定时器频率（常见 250 或 1000），低于 1000 时 1ms 级定时基本不可靠 - 避免在定时器回调里做耗时操作：比如文件 I/O、
curl_exec、未加defer的 DB 查询——会阻塞整个 Worker 事件循环 - 高频场景建议改用
swoole_timer_after链式调用，或在协程中用go(function () { while (true) { ... co::sleep(0.01); } });
定时器 ID 泄漏导致内存涨？每次都要 swoole_timer_clear
每个 swoole_timer_tick 返回唯一整数 ID，不手动清除会持续占用内存，Worker 不重启就一直累积。
- 务必在不再需要时调用
swoole_timer_clear($timer_id)，比如连接断开、任务完成、进程退出前 - 别依赖
onWorkerStop清理——它不一定执行（如被 kill -9 中断） - 如果定时器绑定到某个连接或对象上，推荐把
$timer_id存进该对象属性，销毁对象时一并清理 - 调试泄漏可用
swoole_timer_list()查看当前所有活跃定时器（仅 CLI 模式）
协程服务器里用定时器？优先选 Swoole\Coroutine\Timer
在 swoole_http_server 开启 enable_coroutine => true 后，传统 swoole_timer_* 函数仍可用，但会退化为同步调度；真正轻量、无 ID 管理负担的是协程版。
-
Swoole\Coroutine\Timer::tick(50, function() { ... })返回协程 ID，停用时调用Swoole\Coroutine::cancel($cid) - 协程定时器不占全局 timer_id 池，也不受 Worker 进程数限制，适合 per-request 场景（如请求超时控制）
- 注意：协程定时器回调里不能用同步阻塞函数（如
file_get_contents），否则整个协程调度卡住
高频定时器真正的复杂点不在写法，而在它和事件循环、协程调度、系统时钟三者的耦合。哪怕代码只差一行 swoole_timer_clear，跑几天后内存就飘了；哪怕设了 1ms，实际抖动到 20ms 也未必报错——得自己埋点测。
