Workerman定时器不支持分布式，需用Redis分布式锁保证全局唯一执行；定时任务必须在onWorkerStart中注册并加锁；Timer::add返回ID仅进程内有效，无法动态调整；精度有限，高精度场景应避免使用。
Workerman定时器本身不支持分布式，必须自己加锁
Workerman的Timer::add()只在单个进程内生效，每个子进程都会独立执行一遍。如果你启动了4个Worker进程，又没做任何控制，那同一段定时逻辑就会每秒跑4次。所谓“分布式定时任务”，其实是靠外部协调机制来保证「全局只执行一次」。
最常用也最可靠的方式是Redis分布式锁：所有Worker进程启动时都尝试用SET key value EX 60 NX抢锁，抢到的才注册定时任务；没抢到的跳过。锁过期时间（比如60秒）要明显长于定时任务的间隔，否则可能刚执行完就释放锁，被另一个进程立即抢走，导致重复。
- 锁key建议带服务名+任务标识，例如
lock:report_daily:20260522 - value必须是唯一字符串（如进程PID+毫秒时间戳），避免误删别人持有的锁
- 一定要用
DEL配合Lua脚本原子性释放锁，不能直接DEL - 别依赖
$worker->id === 0这种判断——它只管当前Worker实例，多机器部署时完全无效
定时任务注册必须放在onWorkerStart里，不能写在runAll之前
很多人把Timer::add()直接写在Worker::runAll()上面，结果发现定时器根本没触发。这是因为Workerman的事件循环还没启动，Timer底层靠主进程轮询驱动，没进入循环就注册等于白搭。
正确位置只有$worker->onWorkerStart回调内部。而且要注意：这个回调会在每个子进程启动时都执行一次，所以你要在里面做锁判断或进程ID筛选，而不是指望它只运行一遍。
- 错误写法：
Timer::add(30, $cb); Worker::runAll(); - 正确写法：
$worker->onWorkerStart = function($w) { if (tryLock()) Timer::add(30, $cb); }; - 如果用
$worker->id === 0做单例，仅适用于单机单Worker进程组场景，跨机器无效
Timer::add返回的ID只能del，不能reset或修改间隔
Timer::add()返回的是一个整数ID，不是对象，也没有cancel()、update()之类的方法。你想调整执行频率或停掉某个任务，只能靠Timer::del($id)删掉再重新add()。这意味着：无法在回调函数里动态改下次执行时间；也无法暂停后恢复——只能删了重来。
更麻烦的是，这个ID只在当前进程内有效。你在进程A里拿到ID=123，进程B里Timer::del(123)完全没用，甚至不会报错。
- 想实现“可配置的周期任务”，得自己维护一个任务表（如Redis Hash），每次回调先查最新间隔，再
del + add更新 - 避免在回调里做耗时操作，否则会拖慢整个事件循环，导致后续定时器延迟甚至堆积
- 回调中抛出未捕获异常会终止当前定时器，但不会影响其他定时器或其他进程
精度和稳定性比想象中差，别信“毫秒级”宣传
文档说Timer::add()支持浮点间隔，比如0.1，但实际最小稳定精度约0.1秒，且受系统负载、连接数、CPU调度影响极大。在高并发长连接场景下，Timer::add(0.5, $cb)很可能变成每600~900ms才触发一次。
如果你的任务对时间敏感（比如心跳检测、实时计费），不要依赖Timer做亚秒级调度。要么改用系统cron + HTTP/CLI调用接口，要么换ReactPHP等真正基于event loop的调度器。
- 别写
Timer::add(0.05, $cb)，它不会按50ms跑，大概率卡死或直接被忽略 - 间隔设为0会触发PHP warning并跳过注册；负数则静默失败，无提示
- 所有定时器共享同一个全局调度队列，一个回调卡住，会影响其他定时器的准时性
