<p>crontab无法实现秒级以下调度，因其守护进程每分钟仅轮询一次crontab文件，设计上不支持毫秒/秒级触发，即使配置“ *”也存在2–15秒偏差；Swoole Timer虽支持毫秒级（如tick/after），但精度受事件循环与协程负载影响，且无持久化、不跨进程、不兼容Windows。</p>
为什么crontab做不到秒级以下调度
因为cron daemon本身每分钟只轮询一次crontab文件，它不监听毫秒或秒级事件。哪怕你写* * * * *，实际执行时间仍受系统负载、进程启动延迟影响，常见偏差在2–15秒。这不是配置问题，是设计限制。
- 写
*/1 * * * *想每秒跑一次？日志里只会看到同一分钟内集中触发多次 - 用
sleep 1在脚本里死循环？PHP进程常驻、无法优雅退出、内存泄漏风险高 - 多个定时脚本并发？每次
fork新PHP进程，CPU和内存占用陡增
它只适合备份、日报、日志清理这类对精度无要求、能容忍几分钟偏差的任务。
swoole_timer_tick和swoole_timer_after到底怎么选
两者底层共用最小堆定时器管理器，区别只在生命周期语义：
-
swoole_timer_tick(30000, $callback)返回一个$timer_id，自动重入堆顶，必须手动调用swoole_timer_clear($timer_id)停止，否则一直占内存 -
swoole_timer_after(120000, $callback)是一次性任务，执行完自动释放；返回的$timer_id仅用于提前中止（比如条件变更） - 别在
swoole_timer_after回调里再嵌套调用自己来模拟循环——堆内存碎片化风险高，该用tick就用tick
闭包中若引用$this或外部变量，必须显式use，否则Worker进程重启后变量丢失。
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
资源模型和进程依赖差异极大
crontab每次触发都fork全新PHP进程，开销大但独立：PHP崩了，定时任务照跑；Swoole Timer运行在Worker协程内，零进程开销，但一旦Worker退出（比如reload、OOM、异常终止），所有未清除的定时器就丢了。
-
crontab适合长期稳定、低频、强隔离任务（如凌晨2点导出报表） -
Swoole Timer适合高频、上下文强耦合、需动态启停的任务（如每30秒查一次本机内存、心跳保活、异步重试） - Windows下
crontab不可用，Swoole Timer也不支持Windows（官方明确不兼容）
容易被忽略的精度陷阱
很多人以为swoole_timer_tick(1000, ...)就等于“严格每秒执行”，其实不是。Swoole定时器精度取决于事件循环调度频率和当前协程负载。在高并发或阻塞操作（如同步MySQL查询、未加defer的文件IO）后，回调可能延迟几十毫秒甚至更久。
- 真要毫秒级稳定触发，得确保回调内全是协程安全操作（
co::sleep、mysql->query等） - 避免在回调里做耗时同步操作；否则不仅不准，还会拖慢整个EventLoop
- 没有持久化机制：Swoole Timer不会记录历史触发、失败重试、集群同步，这些得自己补
精度和可靠性从来不是单靠一个函数名就能保证的，得看它跑在哪、干了什么、谁在管它退出。
