时间轮用list而非dict，因其本质是固定槽位的循环数组，需O(1)索引访问、缓存局部性及天然轮转语义；dict则引入哈希开销、内存不连续且无法支持轮转，易退化为线性扫描。
时间轮的核心结构为什么用 list 而不是 dict？
因为时间轮本质是固定槽位的循环数组，每个槽位对应一个时间刻度（比如 100ms），任务按到期时间哈希到对应槽位。用 list 可以保证 O(1) 索引访问和缓存局部性；而 dict 带哈希开销、内存不连续，且无法天然支持“轮转”语义。
常见错误是试图用 dict 存储「时间戳 → 任务列表」，结果在 tick 触发时要遍历所有 key 判断是否到期——这退化成线性扫描，完全失去时间轮意义。
- 槽位总数建议设为 2 的幂（如
64、256），方便用位运算取模：index = timestamp & (size - 1) - 每个槽位存
list或deque，避免频繁插入删除时的list中间操作开销 - 不要在槽位里存原始时间戳，而是存「相对轮次偏移」，否则跨轮时需额外校验
如何安全处理 tick 过程中的任务执行与动态增删？
tick 是单线程推进的，但任务回调可能触发新任务注册或取消，必须避免边遍历边修改当前槽位列表导致 RuntimeError: list changed size during iteration。
典型做法是：每次 tick 先原子地「交换」当前槽位的引用，再遍历旧列表。Python 中可用 clear() 配合临时变量，或直接赋值空列表。
立即学习“Python免费学习笔记（深入）”；
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 错误写法：
for task in self.wheel[current_slot]: task.run(); self.wheel[current_slot].remove(task) - 正确写法：
bucket = self.wheel[current_slot]; self.wheel[current_slot] = []; for task in bucket: task.run() - 若需支持取消，任务对象应带
cancelled标志，tick 时跳过已取消项，而不是从列表中实时删除 - 新增任务必须走统一入口（如
add_task(delay_ms=500)），内部重新计算槽位并追加，不可绕过
time.time() vs time.monotonic()：延时精度到底该依赖哪个？
用 time.time() 会因系统时钟回拨导致任务提前/漏触发；用 time.monotonic() 才能保证单调递增，是时间轮的唯一可靠基准。
但要注意：monotonic() 返回的是纳秒级浮点数，不同平台精度不同（Linux 通常 ~1ns，Windows 可能 ~15ms），所以不能直接拿它做毫秒级槽位索引——需先转成整数毫秒并做截断或四舍五入。
- 推荐初始化方式：
self.base_time = time.monotonic()，后续所有时间差都基于它计算 - 计算槽位时用：
delay_ms = int((target_time - self.base_time) * 1000)，再对轮大小取模 - 避免用
time.perf_counter()——它虽高精度，但不保证跨进程一致，且重启后不连续
多级时间轮怎么避免「降级传播延迟」？
单层时间轮只能覆盖有限时间范围（比如最大延时 = 槽位数 × 刻度）。要支持小时级延时，就得用多级（如 ms 级、sec 级、min 级），但低级轮溢出的任务“降级”到上级轮时，容易因上级轮粒度粗而误差放大。
关键点在于：降级不是简单把任务塞进上级轮的当前槽位，而是要按「剩余精确延时」重新计算其在上级轮中的位置，并记录它本应在哪一刻被提升回下级轮。
- 例如：ms 轮满 64 槽 × 100ms = 6.4s，一个 7s 后执行的任务应放入 sec 轮的第 7 个槽（粒度 1s），而非第 0 个
- sec 轮每 tick 检查自己槽位，把「剩余延时
- 必须用独立的「提升队列」或标记位管理跨轮任务，否则可能重复投递或丢失
真正难的不是结构，是各级轮之间的时间对齐和任务迁移时机——稍有偏差，几小时延时的任务就可能漂移几十秒。实际项目中，除非业务明确需要 >10min 延时，否则优先用单层 + 大槽位（如 4096）更稳。
