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，偏差通常 ms
• 若回调函数执行耗时超过间隔（比如同步 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  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）而非本地变量累加，防止精度差异被放大成逻辑错误

真正影响精度的从来不是参数数字，而是回调里那几行代码的执行路径是否稳定、是否引入阻塞、是否跨进程共享状态。调高数字不如压平逻辑——这是最容易被忽略的硬约束。