swoole_timer_tick(1)不等于每1ms执行一次，因受操作系统调度、CPU负载、回调耗时三重制约，底层epoll_wait或timerfd精度下限约10ms，实际偏差达5–20ms，且过期任务会被丢弃。
精度不是靠“配置”出来的，而是由底层机制和使用方式共同决定的；盲目设 1 毫秒间隔毫无意义，实际触发误差常达 5–20ms。
为什么swoole_timer_tick(1)不等于每 1ms 执行一次
定时器最小有效间隔受操作系统调度、CPU 负载、回调执行时间三重制约。Swoole 底层用 epoll_wait 或 timerfd 实现，其 timeout 精度本身就有下限（Linux 下通常 ≥ 10ms）。即使你传 1，内核也只会按最近可支持的 tick 周期对齐，最终表现就是：回调看似“随机延迟”，甚至漏触发。
- 实测中，设
10ms 间隔，平均偏差约8–15ms；设100ms，偏差通常< 2ms - 若回调函数执行耗时超过间隔（比如同步 HTTP 请求花了 120ms，而间隔是 100ms），后续触发会被跳过或堆积补偿——但 Swoole 默认不累积，而是“丢弃过期任务，从下一个整点再开始”
- 高频 tick（如 ≤ 50ms）必须搭配轻量逻辑，否则 CPU 占用飙升，反而拉低整体精度
需要更高精度时，该用 co::sleep() 自校准
当业务真要求“严格节奏”（例如每秒固定执行 10 次），不能依赖 swoole_timer_tick 的被动触发，得主动控制协程休眠时间并做误差补偿。
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 在协程里用
co::sleep(0.01)（即 10ms）比swoole_timer_tick(10)更可控，因为它是当前协程独占休眠，不受其他定时器干扰 - 每次休眠前记录起始时间，休眠后计算实际耗时，下次休眠时动态调整时长，抵消前次偏差
- 示例逻辑：
$start = microtime(true); for ($i = 0; $i < 100; $i++) { // 执行任务 do_work(); $next = $start + ($i + 1) * 0.01; $sleep = $next - microtime(true); if ($sleep > 0) { co::sleep($sleep); } }
多 Worker 场景下精度一致性更难保障
每个 Worker 进程独立维护自己的定时器堆，不同 Worker 的系统负载、GC 时间、协程调度压力都不同，导致同样配置的 swoole_timer_tick 在各 Worker 中实际触发时刻可能相差几毫秒——这在做全局计数、分布式心跳等场景中容易引发竞态。
- 不要假设所有 Worker 的定时器“同时触发”；如需强一致节奏，应只在
$worker_id === 0的 Worker 中启动核心 tick，其余 Worker 通过Channel或Redis Pub/Sub同步信号 - 避免在
onWorkerStart里为每个 Worker 都启动相同用途的高频 tick（比如每 10ms 刷一次 Redis），这会放大系统抖动 - 若必须多 Worker 并行定时，优先用原子操作（如
INCR、EXPIRE）而非本地变量累加，防止精度差异被放大成逻辑错误
真正影响精度的从来不是参数数字，而是回调里那几行代码的执行路径是否稳定、是否引入阻塞、是否跨进程共享状态。调高数字不如压平逻辑——这是最容易被忽略的硬约束。
