time_wheel::add_timer()必须用绝对时间戳，因相对delay在多线程插入和tick不稳时易致slot集体漂移；应统一用steady_clock::now().time_since_epoch().count()转毫秒存expire_time，避免system_clock跳变，并插入前检查是否已过期。
std::chrono + std::thread 不能撑住万级定时任务，不是精度问题，是设计反模式——每任务一线程、每任务一 sleep、每到期一扫描，三重开销叠加直接让吞吐断崖下跌。
为什么 time_wheel::add_timer() 必须用绝对时间戳而非相对 delay
相对 delay（比如传入 500ms）在多线程插入时极易因调度延迟导致计算偏移；更严重的是，若底层 tick 驱动不稳（如 timerfd 漏 tick 或 epoll_wait 被阻塞），所有基于当前时间推算的 slot 位置都会集体漂移。
正确做法是统一用 std::chrono::steady_clock::now().time_since_epoch().count() 得到纳秒级绝对时间戳，再转成毫秒整数，作为 expire_time 存入节点。这样无论插入时机如何抖动，到期判断只依赖单次读取的全局单调时钟。
- 别用
system_clock：它可能被 NTP 调整，导致定时器提前或跳过 - 别在构造函数里现场算
now() + delay：如果对象跨线程传递，now()值已过期 - 插入前务必检查
expire_time <= now()，这类“已过期”任务应立即投递，不进轮子
优先级怎么嵌进 time_wheel::tick() 不拖慢遍历性能
不能在每个 bucket 里套一个 std::priority_queue，否则遍历时要对桶内全部任务做堆 pop，复杂度从 O(k) 变成 O(k log k)，k 是桶内任务数——100 个同 tick 高频任务就能吃掉 20% CPU。
立即学习“C++免费学习笔记（深入）”；
真正高效的做法是把优先级编码进排序键：用 (expire_time << 2) | priority 构造 uint64_t 主键，在桶内用 std::list 存储，插入时按主键有序插入（O(k) 扫描找位点），但 tick 触发时仍可顺序遍历执行（O(k)）。关键在于：同一毫秒内高优先级任务一定排前面，而跨毫秒任务严格按时间先后。
-
priority建议用 2 bit 编码（0–3），避免左移后溢出或干扰时间高位 - 比较函数中必须用
>（因为std::priority_queue默认大顶堆），但你不用它——改用带哨兵的链表插入更可控 - 如果业务要求「同时间下优先级完全抢占」，就别省那点插入开销，老实用
std::vector<TimerTask>+std::sort每次 tick 前局部排序
多级时间轮降级时最常踩的坑：rotation 计算错误
单层轮子覆盖范围有限（比如 64 槽 × 256ms = ~16s），长周期任务必须降级到低频层。常见错误是直接拿剩余时间除以新层粒度，忽略“已走过圈数”的余数归属。
例如：一个 120s 任务在毫秒层（粒度 1ms）会算出 120000 圈，显然不合理。应先按层级粒度分级：第 0 层（毫秒）管 0–255ms，第 1 层（秒）管 1–63s，第 2 层（分钟）管 1–63min……每层槽数固定为 64，降级公式为：level = min(7, __builtin_clzll(timeout_ms) - 56)（GCC/Clang），然后用 timeout_ms >> (level * 6) 算该层 offset，再取模得 slot。
- 别用浮点
log2：慢且有精度误差，__builtin_clzll是位运算，零误差 - 降级后必须重算剩余时间，不是简单减去上层最大值——否则 65s 任务会落到秒层 slot 1，实际应是 slot 1、level 1、rotation 0
- 所有层级共享同一 tick 源（如 timerfd），但每层有自己的指针和旋转计数器，不能共用 current_slot_
timerfd + epoll 驱动 time_wheel::tick() 时 read() 必须非阻塞
一旦 timerfd 设置为阻塞模式，read(tfd, &exp, sizeof(uint64_t)) 在没有到期事件时会挂起整个事件循环，epoll_wait 就卡死，所有网络 IO 和定时任务全停摆。
初始化必须加 TFD_NONBLOCK 标志：int tfd = timerfd_create(CLOCK_MONOTONIC, TFD_NONBLOCK);。收到 EPOLLIN 事件后，read 返回 -1 且 errno == EAGAIN 是正常现象，说明本次 tick 已被清空，直接调用 tick() 即可；若返回 8 字节，则 exp 是自上次以来触发次数，需循环调用 tick() 多次（防止漏 tick）。
- 别在 epoll 回调里直接执行用户回调：可能抛异常或阻塞，应 push 到工作线程池
-
it_interval必须设为非零值，否则只触发一次，轮子就停了 - 每次
read后必须清空计数，否则下次 EPOLLIN 不会再通知——这是 timerfd 的语义，不是 bug
真正难的不是写完八层轮子，而是让每一层的 rotation、每一槽的插入顺序、每一次 read 的计数清空都咬合严丝合缝。任何一处错位，都会在高负载下放大成毛刺、漏触发或内存泄漏——这些地方没日志、不报错，只能靠 perf record + 自定义 tracepoint 抓。
