resample丢数据因默认右闭区间且不填充，需set_index、closed=’left’、label=’left’并接asfreq或ffill；重复时间戳须先drop_duplicates；islice流式慢因线性扫描，应改用chunksize或np.searchsorted；sleep控速不准，需perf_counter动态校准。
回放时时间戳对不齐，pd.DataFrame 的 resample 为啥总丢数据
时间序列回放最常卡在这儿：原始数据采样不均匀，用 resample 强制对齐后，部分时间点直接消失，或者值被错误聚合。根本原因是 resample 默认按右闭区间切分，且不自动填充缺失时间点。
- 先用
set_index('timestamp')确保时间列是DatetimeIndex，否则resample会静默失效 - 显式指定
closed='left'+label='left'，和多数实时系统的时间语义对齐 - 必须接
.asfreq()或.fillna(method='ffill')，resample自身不补点 - 如果原始数据里有重复时间戳，先跑
df.drop_duplicates(subset=['timestamp'], keep='last')，否则聚合逻辑会错乱
用 itertools.islice 做流式回放，为什么 CPU 占用飙到 100%
想省内存用生成器逐条吐数据，结果发现 islice 在大文件或高频率数据下反而更慢——它本质是线性跳过，没做索引优化，每次调用都从头遍历。
- 真要流式处理，优先用
pandas.read_csv(..., chunksize=N)，底层走 C 实现，比纯 python 生成器快 3–5 倍 - 如果必须用迭代器，把时间戳列预加载成
numpy.Array，用np.searchsorted()定位起始位置，避免全量扫描 - 别在循环里反复调用
datetime.strptime()，提前用pd.to_datetime()转好存在数组里 - 注意
islice(iterator, start, stop)的start是从当前迭代器位置算起，不是绝对索引，容易偏移
回放速度忽快忽慢，time.sleep() 控不住节奏
sleep 只保证“至少睡这么久”，但系统调度、GC、IO 阻塞会让实际间隔漂移，尤其在 linux 上误差常超 ±20ms，对毫秒级回放就是灾难。
- 用
time.perf_counter()做基准计时，每步计算「该发时间 – 当前时间」，再传给sleep() - 如果误差累计 > 5ms，直接跳过 sleep，避免越睡越滞后；误差
- 关键路径禁用
print()和日志，字符串格式化开销远超预期，改用sys.stdout.buffer.write()写二进制 - Python 的 GIL 会让多线程 sleep 不准，单线程 + 精确计时比多线程 + sleep 更稳
回放时 kafka / redis 写入失败，重试逻辑反而让时间线错乱
网络抖动导致消息写入失败，简单重试会把本该 t=1000ms 发的消息拖到 t=1050ms 才发出，破坏时间保序性。
立即学习“Python免费学习笔记（深入）”；
- 所有发送操作必须带原始时间戳字段（如
'ts_origin': 1000），服务端按此排序，不依赖接收时间 - 重试队列用
heapq按ts_origin排序，而不是 FIFO；失败消息插回堆顶，下次优先重试最早那条 - 设置最大重试次数（建议 ≤3），超时直接丢弃并告警，别让一条失败消息拖垮整条时间线
- Redis 用
LPUSH + BRPOPLPUSH实现带超时的可靠队列，比纯PUBLISH/SUBSCRIBE更可控
时间精度和顺序保障不是靠某个函数调对了，而是每个环节都得主动声明自己的时间契约——数据源带什么时间戳、中间件怎么透传、下游怎么解释。漏掉任意一环，回放就只是“看起来在动”。