1. 课程导入与盘口回放认知

在交易类系统的开发与教学里，“盘口”指的是某一时刻买卖双方在订单簿上的挂单分布，包括买一至买五、卖一至卖五的价格与数量，以及成交明细、逐笔委托等实时数据。而“盘口回放”，是把一段已经发生过的行情按原始时间顺序重新播放出来，让使用者像当时一样逐帧观察价格、挂单和成交的变化。它不是简单的录像，而是对时间序列数据的可控重演——可以暂停、快进、逐笔步进，也可以随时跳回某个时间点重新观察。

理解盘口回放的价值，先要理解“实时盘口”的局限。实时行情是单向流逝的，一个关键的大单撤单可能只持续几百毫秒，人眼很难捕捉；而回放把这段流逝的时间变成可反复检视的对象。因此，盘口回放的核心价值可以概括为三点：把不可逆的时间变成可回溯的对象、把瞬时的盘口状态变成可逐帧对比的序列、把主观的盘感变成可验证的证据。这三点决定了它在复盘分析、策略验证和教学演示三类场景中都是基础设施级别的工具。

三类典型应用场景

复盘分析关注“当时发生了什么、为什么”。交易者需要回看某只标的在某个时段的挂单变化，判断某次快速拉升前是否有连续的买单堆积、卖压是否被逐步吃掉。回放工具要能按时间轴定位、逐笔前进，并在盘口数字变化时给出清晰的视觉提示。

策略验证关注“如果按规则操作，结果会怎样”。这里回放不只是看，还要能驱动计算：把逐笔行情喂给一个策略函数，观察它在每个时间点产生的信号，并与后续价格走势对照。此时回放的数据精度、时间戳对齐方式和事件顺序就变得非常关键，任何一处错序都会让验证结论失真。

教学演示关注“如何让学习者看清”。讲师需要把一段典型行情拆成可讲解的步骤，在关键节点暂停并标注，让学员理解盘口语言。回放页面因此需要良好的可读性：价格档位对齐、数量变化高亮、时间轴可拖动。

为什么用 HTML 交互页面来做回放

实现盘口回放的技术路线不少：桌面客户端、脚本离线分析、甚至视频录制。相比之下，HTML 交互页面有几个直接优势。第一是零安装、易分发，一个链接就能让学员或同事打开，不需要配置运行环境。第二是交互能力强，浏览器天然支持拖拽、点击、悬停、动画，时间轴拖动和盘口高亮都能用原生 DOM 与 CSS 实现。第三是数据与视图解耦方便，行情数据可以用 JSON 组织，渲染逻辑独立，便于替换数据源或调整展示样式。第四是可嵌入、可扩展，页面既能独立使用，也能嵌进更大的分析平台，后续接入策略计算模块时改动成本低。

当然也要看到边界：浏览器处理超大规模逐笔数据时需要做分页或分段加载，毫秒级高频回放对渲染性能有要求。这些正是后续章节要解决的具体问题，而不是否定这条路线。

整体开发路线图

本课程按“认知—数据—引擎—视图—交互—验证”的顺序推进，可以理解为一条从原始数据到可用页面的构建链。第一步是明确回放对象与数据格式，把逐笔委托、逐笔成交和盘口快照统一成带时间戳的事件序列；第二步是构建回放引擎，负责事件排序、订单簿状态维护和播放控制；第三步是页面视图，把买五卖五档位、成交明细、时间轴组织成清晰的布局；第四步是交互逻辑，实现播放、暂停、步进、跳转和速度调节；第五步是场景化增强，针对复盘、验证、教学分别补充标注、信号叠加和讲解辅助；最后是性能与正确性验证，确保回放顺序与真实行情一致。

为了让这条路线可执行，先给出一个最小可用的数据事件结构示例。下面的字段是后续引擎和视图共同依赖的契约，示例数值仅用于说明格式，不代表真实行情：

{
  "ts": 1700000000123,
  "type": "order",          // order=逐笔委托, trade=逐笔成交, snapshot=盘口快照
  "side": "buy",            // buy / sell
  "price": 10.25,
  "volume": 300,
  "seq": 10087              // 同一毫秒内的稳定排序序号
}

这里有两个容易被忽略但影响很大的细节。其一是时间戳精度：如果只保留到秒，同一秒内的多笔事件顺序就会丢失，回放结果与真实盘口可能不一致，因此应保留毫秒并在同一毫秒内用 seq 做稳定排序。其二是事件类型区分：委托事件改变订单簿挂单，成交事件消耗挂单并产生成交明细，快照事件则用于校验引擎重建的订单簿是否与原始盘口一致。三者混在一起处理，是初学者最常见的错误来源。