std::chrono+std::thread无法支撑万级定时任务，因线程开销大、sleep精度低（linux下误差10–50ms）、唤醒抖动强且不支持动态增删；应采用时间轮架构，通过环形槽位与单指针推进实现o(1)插入和批量触发。
时间轮调度器为什么不能直接用 std::chrono + std::thread 循环休眠实现
因为精度失控、唤醒抖动大、无法支持海量定时任务。每次 std::this_thread::sleep_for 都受系统调度延迟影响，Linux 下典型误差 10–50ms；任务量一过千，线程频繁唤醒+遍历导致 CPU 毛刺明显。真实高并发场景（如网关每秒数万连接心跳）必须避免线性扫描。
单层时间轮的哈希槽冲突怎么破——关键在 slot_count 和 tick_duration 的耦合设计
常见错误是把 slot_count 设成固定 64 或 256，结果长周期任务全挤在少数槽里，退化成链表遍历。正确做法是按业务最大容忍延迟反推：比如要求 100ms 内触发，则 tick_duration = 100ms；再按预期最大并发定时任务数 N，取 slot_count ≥ N / (max_lifetime_ms / tick_duration)。例如 10 万个 10s 内到期的任务，slot_count 至少要 100000 / (10000 / 100) = 1000。
-
tick_duration必须是操作系统时钟可稳定提供的最小粒度（推荐 10ms～100ms），别设 1ms - 每个槽用
std::vector<timerentry></timerentry>而非std::list，减少指针跳转开销 - 插入时不做排序，执行时才按
expire_time字段过滤，避免插入成本上涨
TimerEntry 对象生命周期管理为什么必须用 std::shared_ptr + 弱引用回调
裸指针或 unique_ptr 在多线程取消定时器时极易 dangling：A 线程刚调 cancel()，B 线程已在执行槽内回调，此时对象已被析构。标准解法是让 TimerEntry 持有 std::weak_ptr<self></self>，回调入口先 lock()，失败则直接 return。
void on_timeout() {
auto self = self_ref_.lock();
if (!self) return; // 对象已销毁，不执行业务逻辑
callback_();
}
注意：self_ref_ 必须在构造时就绑定到 shared_from_this()，不能在回调里临时构造 shared_ptr。
多级时间轮（Hierarchical Timing Wheel）真有必要吗？看你的最长定时周期
单层轮只适合「最大超时 ≤ slot_count × tick_duration」的场景。如果需要支持 1 小时后触发的任务，又不想把 slot_count 拉到 36000（浪费内存），就得上二级轮：第一级管 0–60s（60 槽 × 1s），第二级管 1m–60m（60 槽 × 1m）。关键逻辑在插入时自动降级：if (delay > 60s) { insert_to_second_level(); }，但要注意跨级迁移必须原子——用 std::atomic<bool></bool> 标记迁移中状态，防止重复插入或漏触发。
真正难处理的是“边界时刻”：比如当前时间是 12:00:59.999，插入一个 12:01:00.000 的任务，两级轮都可能错过一次 tick。必须在每次 tick 前后做一次“兜底扫描”，检查是否漏掉刚好落在 tick 边缘的任务。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
