Swoole协程中禁用sleep()，须用Timer::tick()/after()实现非阻塞定时；tick精度约10ms且受负载影响，高频回调需加锁或原子操作；定时器必须在onWorkerStart中创建，避免内存泄漏。
定时器在 Swoole 协程里不能用 sleep() 模拟
协程里调用 sleep() 会阻塞整个协程调度器，不是“当前协程休眠”，而是让所有协程都卡住。这是最常踩的坑——你以为只是等几秒，结果整个服务响应停滞。
- 必须用
Swoole\Timer::tick()或Swoole\Timer::after()，它们是异步非阻塞的 -
tick()适合周期性任务（比如每 5 秒查一次缓存状态），after()适合单次延迟执行（比如 30 秒后清理临时文件） - 回调函数内默认在协程上下文中运行，可直接用
co::sleep()、MySQL::query()等协程 API
Swoole\Timer::tick() 的参数陷阱和精度问题
很多人设了 1000 毫秒间隔，却发现实际执行间隔忽长忽短，甚至漏触发。这不是 bug，是设计使然：Swoole 定时器基于 epoll/kqueue 事件循环，最小精度约 10ms，且受 CPU 负载、回调执行时间影响。
- 第一个参数是毫秒数，但传
1不等于“每 1ms 执行”，实际最低有效值建议 ≥ 10 - 回调函数如果执行太久（比如同步 HTTP 请求、大数组遍历），下一次 tick 会被推迟，无法累积补偿
- 若需更高精度或严格节奏（如每秒固定执行 N 次），得自己用
co::sleep()+ 循环校准，但要注意避免 busy-wait
协程定时任务里访问共享资源要加锁
多个 tick 回调可能并发修改同一个变量或写同一张表，比如统计计数器、更新 Redis key。Swoole 不会自动帮你串行化这些回调。
- 不要直接操作全局变量或静态属性，例如
$count++在高频率 tick 下大概率出错 - 用
Swoole\Coroutine\Channel做任务队列，把修改逻辑发到单个消费者协程里处理 - 对 Redis 或 MySQL，优先用原子操作：
INCR、UPDATE ... SET x = x + 1，而不是先查再改 - 如果必须用锁，用
Swoole\Coroutine\Lock（注意它只在当前进程内有效，多 Worker 需配合 Redis 分布式锁）
定时器没触发？先检查 onWorkerStart 里是否漏了初始化
在 Swoole Server 中，Timer::tick() 必须在 Worker 进程启动后才能创建。如果写在 onStart 或全局作用域，会报错 PHP Warning: Swoole\Timer::tick(): must be called in the worker process，或者干脆静默失败。
- 正确位置是
onWorkerStart回调内，每个 Worker 进程各建一套定时器 - 别在
onReceive或onRequest里反复调用tick()，会导致定时器无限叠加，内存泄漏 - 用
Swoole\Timer::clear()主动销毁不再需要的定时器，尤其是动态创建的场景（如用户连接时启动专属心跳）
协程定时器的“精准”是相对的，真正的难点不在怎么设间隔，而在于回调里做了什么——IO 是否协程化、有没有隐式同步调用、资源竞争是否被忽略。这些地方一松懈，定时逻辑就从“辅助工具”变成“故障源头”。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
