Workerman中不能用sleep()，必须用Timer::add()替代，否则整个worker进程会卡死；因为sleep()是同步阻塞调用，会使事件循环停摆，导致新连接失败、心跳断开、定时器失灵。
Workerman里不能用sleep()，必须用Timer::add()替代，否则整个worker进程会卡死。
为什么sleep()在Workerman中是危险操作
Workerman是事件驱动的常驻进程，所有连接、定时器、IO都跑在同一个事件循环里。sleep()是同步阻塞调用，一旦执行，当前worker进程就彻底停摆：新连接进不来、已有连接心跳断开、其他定时器全部失灵。你看到的“连接超时”“定时器不触发”“消息收发延迟”，大概率就是悄悄用了sleep()。
常见错误场景包括：
- 在
onMessage回调里写sleep(3)模拟处理耗时，结果整条连接线程被锁死 - 在定时器回调里调用
file_get_contents()或mysqli_query()这类阻塞函数，效果等同于sleep() - 把
sleep()当成“延时发送”的手段，比如“用户下单后5秒发通知”，实际导致服务不可用
Timer::add()怎么用才安全
它不是暂停当前流程，而是在事件循环中“预约一个将来执行的回调”。关键是要管住回调里的行为，避免二次阻塞。
- 回调函数里禁止任何阻塞操作：不用
sleep()、不用file_get_contents()、不用mysqli_query()；改用协程客户端（如Workerman\Http\Client）或异步DB驱动 - 需要链式延时（比如1秒→2秒→执行），必须在第一次回调里再调一次
Timer::add()，不能靠嵌套sleep() - 只执行一次的延时任务，第四个参数传
false：Timer::add(5000, $callback, [], false) - 务必保存返回的
$timerId，并在不再需要时显式调用Timer::del($timerId)，否则内存泄漏+定时器堆积
延时任务中如何避免连接失效和上下文丢失
直接在onMessage里写Timer::add(5000, function() { ... })是高危写法——5秒后回调执行时，原始$connection可能已断开、被回收，$this也可能指向无效对象。
- 延时前先检查连接状态：
if ($connection->isConnected()) { ... } - 把必要数据（如
$connection->id、用户ID、订单号）作为$args传入回调，而不是闭包引用整个$connection - 复杂业务逻辑（如“30分钟未支付关单”）建议封装成独立类，构造时传入Worker实例和ID，在
handle()里做完整状态校验与DB操作 - 多worker部署时，
Timer::add()不跨进程共享，需配合Redis锁或延迟队列防重复执行
高频延时任务的性能陷阱
每秒创建上百个Timer::add()，哪怕只执行一次，也会快速拖垮worker：内存持续上涨、响应变慢、日志无明显报错，但监控能看到CPU空转、内存占用飙升。
- 高频触发场景（如实时风控打标），改用单个长周期定时器轮询队列，而不是为每个事件单独建定时器
- 延时精度要求不高（如“5分钟内执行”）时，可批量聚合任务，减少定时器数量
- 真正容易被忽略的是生命周期管理——没人清理的定时器，就像没关的数据库连接，跑几天后问题才集中爆发
