定时器优化核心是聚合调度而非调参：用单一定时器统一驱动任务队列，优先选用after()替代tick()，回调内仅做轻量就绪判断，重操作须前置或异步化。
定时器本身轻量，但滥用会迅速拖垮系统——高频短周期、大量独立定时器、回调阻塞，三者叠加就是性能雪崩的起点。真正有效的优化，不是调参数，而是从任务组织方式入手：先聚合，再调度。
把零散任务收拢成一个主定时器
与其为每项小操作单独启一个 tick(10)，不如用一个稳定的 tick(100) 统一驱动。在回调里遍历任务队列，只执行已就绪的任务。这样既降低事件循环查找开销（红黑树 O(log n) 查找压力大减），又避免成百上千个定时器节点堆积内存。
- PHP Swoole 示例中，100ms 主轮询处理队列，OPS 提升近 6 倍，最大延迟反而下降
- Node.js 场景下，也建议用递归
setTimeout替代setInterval，规避定时漂移带来的隐性重叠执行 - Java Spring 中，避免多个
@Scheduled(fixedDelay = 100)方法，改用单个调度器 + 内部状态分发
一次性任务优先用 after()，别用 tick() 模拟
需要“3秒后发通知”，就直接 Swoole\Timer::after(3000, $callback)；若写成 tick(100) 并在回调里计数判断，等于凭空多出 30 次无意义轮询和节点管理。
- 每次
tick()都新增一个定时器节点，需插入红黑树、参与下次超时计算 -
after()是单次节点，触发即自动清理，生命周期清晰，资源开销最小 - Spring 中对应的是
@Scheduled(fixedDelay = ...)与TaskScheduler.schedule()动态提交的一次性任务之别
任务就绪判断要轻量，别在定时器回调里做重活
定时器回调是事件循环的“快车道”，必须秒级完成。任何数据库查询、远程调用、复杂计算都该前置或异步化。
- 正确做法：由业务逻辑提前标记任务就绪（如写入 Redis flag 或推送到 Channel），定时器只做“检查+触发”
- 错误示范：回调里执行
$db->query("SELECT ... WHERE next_run —— 每次都查库，IO 叠加 CPU，延迟必然飙升 - 进阶技巧：结合协程 Channel，让任务“主动唤醒”定时器，彻底消除轮询
及时清理，别让过期定时器变成内存幽灵
启动了就要负责到底。忘记 Swoole\Timer::clear($id)，或没处理好异常退出路径，会导致定时器节点长期滞留，占用内存并持续参与超时比对。
- 协程函数内启动的定时器，应在协程退出前明确清除；可封装
defer式清理逻辑 - Java 中使用
ScheduledFuture.cancel(true)确保终止，尤其在动态任务场景下 - 监控手段：定期统计活跃定时器数量，突增即告警——这是任务泄漏的早期信号
