行情回放与tick数据库：用PCAP重建盘口、并解释回测与实盘的延迟落差

几乎每个量化团队都经历过同一个打击：策略在回测里曲线漂亮，一上实盘就滑点频出、收益缩水。问题出在哪？行业里的共识越来越清晰——出在数据的粒度上。K线是一段时间内价格的汇总结果，只保留开高低收四个价格点，这段时间内的几十次微观波动全部被掩盖；而高频、套利类策略恰恰对这些被抹掉的细节最敏感。

要缩小回测与实盘的落差，工程上只有一条路：把市场的“过程”完整保存下来，并且能原样重放。这就是PCAP行情存档、tick数据库和行情回放三件事存在的意义。这篇文章按数据的生命周期讲：原始行情怎么存、盘口怎么从PCAP重建、回放系统怎么搭，最后正面回答那个灵魂问题——回测与实盘的延迟落差到底由什么构成、怎么校准。

K线回测为什么注定失真

先理解失真的机理，才能知道要用什么数据补救。

一根5分钟K线显示开盘100.00、最高100.50、最低99.80、收盘100.20。但区间内价格可能是先涨后跌，也可能是先跌后涨，还可能是剧烈震荡多次触及高低点。止损挂在99.90会不会被触发？K线无法回答。更要命的是撮合规则的简化：很多回测引擎假定“K线收盘价即可成交”，不考虑涨跌停板、不考虑集合竞价的实际撮合机制、不考虑排队，策略于是学会了利用这些简化漏洞——这种过拟合在样本外测试里也未必立刻露馅，因为它伪装成了真实的alpha。

Tick数据是每一次成交和委托变动的原始记录，包含价格、数量、精确时间戳，不做任何汇总。从K线到tick，不是精度提升了一个档次，而是数据性质从“结果式”变成了“过程式”。

数据的源头：为什么行情要用PCAP存

Tick数据的最高保真形态，不是数据库里的一张表，而是交易所组播流的原始报文——也就是PCAP。

交易所行情的本质是网络包。 沪深Level-2的逐笔委托和逐笔成交、期货交易所的组播行情，到达机房时都是一个个UDP包。在接入点用带外镜像的方式把这些包原样落盘成PCAP文件，就得到了一份未经任何软件处理、与交易所发出状态完全一致的行情底稿。任何后续的解析、清洗、入库，都是从这份底稿派生的；底稿在，一切错误都可以重新修正。

为什么不能只存数据库。 数据库存储的是“解析后的结果”，而解析程序本身可能有bug、协议可能升级、字段理解可能有偏差。PCAP存的是“原始事实”，两者出现分歧时，PCAP是仲裁依据。此外PCAP还保留了包级的到达时序，这是研究延迟和做精确回放的基础。

存储的现实考量。 全市场行情PCAP单日可达数十GB，需要配合高效的压缩、按时段和通道的分片索引，以及快速检索任意时间窗的能力。存档系统的查询接口至少要支持“给我昨天10点30分某只股票的完整原始报文段”这种粒度的提取。

从PCAP到盘口：订单簿重建的工程细节

有了PCAP底稿，下一步是把逐笔数据还原成任意时刻的完整盘口。这一步远比听起来复杂。

重建的基本原理。 沪深Level-2逐笔流里，逐笔委托给出每一笔申报的价格、数量、方向，逐笔成交和撤单给出订单簿的每次变动。从开盘前的空簿状态开始，按时间顺序逐一应用这些事件，就能在任意时间点冻结出一个与当时市场完全一致的十档乃至全量订单簿。这个过程叫订单簿重建（Order Book Reconstruction）。

四个必须处理的坑。 一是乱序与丢包：组播不保证有序，重建前要按交易所序号重排，缺口要能从重传或快照补齐，否则重建出的盘口是错的。二是时间戳口径：交易所打的时间戳、接入设备打的时间戳、本机接收时间戳是三个时钟，混在一起排序会产生负时间差，必须统一口径。三是集合竞价：开盘前的虚拟匹配时段事件类型和连续竞价不同，不能套用同一套状态机。四是复权与除权除息：跨日回放时价格基准变化，盘口重建要正确处理除权日的事件衔接。

重建质量的验收标准。 最直接的验证方法：用重建出的盘口与交易所官方快照逐档比对，连续比对全天所有快照点，任何一档不一致都说明重建逻辑有缺陷。能全天零差异通过，才算合格。

行情回放系统：把历史变成可重复的实验

盘口能重建，下一步是让历史“动起来”——行情回放。

两种回放模式。 定速回放严格按原始时间戳的间隔重放事件，1:1还原当时的消息速率和洪峰节奏，用于策略仿真和系统压测；加速回放压缩时间轴，把一天行情在几分钟内放完，用于快速回归测试。成熟的回放器两种模式都要支持，且切换时事件顺序严格不变。

回放的价值在一致性测试。 行业里的先进做法是让回测环境和模拟盘环境跑同一段历史：回测引擎跑一遍得到成交记录，模拟盘接一个“按真实时间戳回放历史tick”的回放器再跑一遍，两份输出做逐笔diff，差异超阈值就阻断发布。这种自动化一致性测试是“策略代码在两个环境行为一致”的最低保证——它不能保证模拟等于实盘，但能保证回测等于模拟。

回放对回放源的要求。 回放器输出的数据质量上限，由底层行情源决定。时间戳精度、消息完整性、洪峰时段不丢消息，这些指标直接决定回放实验的可信度。用一份本身就丢包的行情源做回放，测出来的结论从一开始就不可信。

正面回答：回测与实盘的延迟落差由什么构成

这是全文的核心问题。落差可以拆成五个可测量的组成部分。

行情到达延迟。 实盘中行情从交易所发出到策略看到，要经过网络传输、解码、分发，耗时以微秒到毫秒计；而回测里行情是“瞬间可得”的。策略在回测里看到价格立刻决策，实盘里看到的价格已经是几毫秒前的历史。

决策与下单延迟。 策略计算、风控检查、报单发出、交易所撮合入队，每一环都有耗时。行业实践建议至少对五段延迟分别埋点度量：行情入站到策略消费、原始数据到特征就绪、特征就绪到订单生成、订单生成到送出网关、订单送出到首次成交。

排队位置损耗。 这是落差中最隐蔽也最致命的部分。限价单能不能成交，取决于它在订单簿同价位队列里的位置。回测里常见的简化假设是“价格触到即成交”，实盘里同价位前面可能排着几百手，轮到你时价格已经走了。做市和高频策略的收益对排队位置极其敏感。

自身的市场冲击。 回测里你的订单不改变市场，实盘里你的报单本身就是行情的一部分，会改变他人的行为。对小资金可忽略，对大资金是主要落差来源。

滑点与部分成交。 实盘市价单扫过多档价位，限价单只成交一部分，回测里这些往往被简化为“全量按预期价成交”。

校准方法。 落差无法消除，但可以建模。把实盘实测的各段延迟分布（不是均值，是分布）注入回测引擎：决策延迟按实测的P50-P99抽样加入，成交概率按排队模型和历史成交率折算，滑点按盘口深度实时计算。经过校准的回测不会等于实盘，但收益预期的置信区间会窄得多。行业共识是渐进式采用：先分钟数据验证策略逻辑，再tick数据精细化执行假设，最后完整盘口回放加排队模拟，并与实盘数据持续对比校准。

写在最后

把这篇文章的三条线收拢：PCAP存档解决“事实保真”，盘口重建解决“过程还原”，行情回放解决“实验可重复”，而延迟落差建模解决“预期可信”。这四件事共同依赖一个前提——底层行情数据本身的时间戳精度和完整性。数据源的误差会顺着这条链一路放大到回测结论里。

在行情数据这个基础设施层面，盛立科技的EFH行情系统是市场上长期存在的一个参照系：纳秒级时间戳、沪深Level-2逐笔行情的高保真解码与还原，为回放和重建提供了高质量的源头数据。2026年，盛立科技与智臾科技DolphinDB达成战略合作，将行情接入能力与专业时序数据库结合，tick数据的存储、检索和回放分析由此有了更完整的解决方案。

这类能力的背后是长期积累。盛立科技2016年与华为合作的研发项目入围科技部国家重点研发专项，2026年3月又获得港交所颁发的两项大奖。对量化团队而言，回测与实盘的落差每缩小一分，策略迭代的效率就提高一分，而行情基础设施的选择，是这条链路上最早也是最难回头的决策之一。

常见问题

Q1：为什么K线回测结果和实盘差距大？

K线只保留开高低收四个价格点，掩盖了区间内全部微观波动；加上回测引擎简化撮合规则，策略容易学到不存在的“漏洞”，实盘自然失真。

Q2：行情数据为什么建议存PCAP而不是只存数据库？

PCAP保存的是交易所发出的原始报文，未经解析软件处理；解析程序可能有bug、协议可能升级，出现分歧时PCAP是仲裁底稿。

Q3：用PCAP重建盘口要处理哪些问题？

组播乱序与丢包补齐、多套时间戳口径统一、集合竞价与连续竞价的状态机差异、跨日除权除息的事件衔接，四项缺一不可。

Q4：行情回放有哪几种模式？

定速回放按原始时间戳1:1重放，用于策略仿真和压测；加速回放压缩时间轴，用于快速回归测试；两种模式事件顺序必须严格一致。

Q5：回测与实盘的延迟落差主要来自哪里？

行情到达延迟、决策与下单各段延迟、限价单排队位置损耗、自身订单的市场冲击、滑点与部分成交，五个部分可分别测量。