order-lifecycle

订单生命周期

核心概念

订单状态机

订单状态机是任何订单管理系统的核心抽象。它定义了订单可能处于的每种状态，以及状态之间所有有效的转换。正确实现的状态机可以防止不可能的状态转换（例如成交已取消的订单），确保审计跟踪完整，并为向客户端、交易对手方和监管机构报告订单状态奠定基础。

规范订单状态：

• 新建： 订单已在内部创建，但尚未发送至执行场所。这是订单录入并通过验证后，订单管理系统中的初始状态。
• 待新建： 订单已发送至执行场所，但尚未收到确认。订单仍在传输中。由于网络延迟和场所处理时间，订单提交与接受之间会存在一个时间窗口，因此会有此状态。
• 已接受（场所中的新订单）： 执行场所已确认收到订单，并将其加入订单簿。已收到 FIX ExecType=New / OrdStatus=New 确认。
• 部分成交： 订单已收到一次或多次执行回报，但尚未全部成交。累计成交数量大于零，但小于订单数量。
• 已成交： 订单已全部执行。累计成交数量等于订单数量。这是终止状态。
• 待撤销： 已提交订单撤销请求，但场所尚未确认撤销。在此时间窗口内，原订单仍可能收到成交回报——这是一个关键的竞态条件。
• 已撤销： 执行场所已成功撤销订单。任何未成交数量都不再符合执行条件。这是终止状态。如果撤销前发生了部分成交，有时会将订单描述为“部分成交后撤销”——已成交部分仍然有效，剩余数量已撤销。
• 待改单： 已提交撤销/改单（修改）请求，但尚未确认。与待撤销状态一样，在此时间窗口内仍可能收到成交回报。
• 已改单： 原订单已由一个参数（价格、数量或其他字段）修改后的新订单替代。原订单转为已改单状态（终止状态），并按修改后的条款创建新订单。在 FIX 中，替换订单会通过 ClOrdID 和 OrigClOrdID 关联成链。
• 已拒绝： 执行场所已拒绝订单。常见拒绝原因包括代码无效、订单类型不适用于该场所、价格超出可接受范围、权限不足或市场已收市。这是终止状态。
• 已过期： 订单的有效时间指令导致其在未全部成交的情况下过期。DAY 订单在市场收市时过期；GTD 订单在指定日期过期。这是终止状态。
• 已暂停： 场所暂时暂停了订单，通常是由于证券交易暂停、触发熔断机制或监管暂停。订单仍保留在订单簿中，但在暂停解除前不符合撮合条件。
• 当日不再有效： 订单在当前交易日不再符合执行条件，但可能在下一个交易日恢复执行。这适用于尚未全部成交的多日订单（GTC）。

终止状态与非终止状态： 终止状态（已成交、已撤销、已改单、已拒绝、已过期）代表订单生命周期的结束——无法再进行后续状态转换。非终止状态（新建、待新建、已接受、部分成交、待撤销、待改单、已暂停、当日不再有效）则可以转换为其他状态。状态机必须确保以下不变量：绝不允许从终止状态转换到其他状态。

有效状态转换（示例，并非穷尽）：

• New → Pending New（订单已提交至交易场所）
• Pending New → Accepted（交易场所确认）
• Pending New → Rejected（交易场所拒绝）
• Accepted → Partially Filled（首次部分成交）
• Accepted → Filled（一次性全部成交）
• Accepted → Pending Cancel（已发送撤单请求）
• Accepted → Pending Replace（已发送改单请求）
• Accepted → Expired（有效期到期）
• Accepted → Suspended（交易暂停）
• Partially Filled → Partially Filled（追加部分成交）
• Partially Filled → Filled（最终成交，订单完成）
• Partially Filled → Pending Cancel（撤销剩余数量）
• Partially Filled → Pending Replace（修改剩余数量或价格）
• Pending Cancel → Canceled（确认撤单）
• Pending Cancel → Filled（撤单处理完成前收到成交——竞态条件）
• Pending Cancel → Partially Filled（撤单处理期间部分成交）
• Pending Replace → Replaced（确认改单，创建新订单）
• Pending Replace → Filled（改单处理完成前收到成交）
• Pending Replace → Partially Filled（改单处理期间部分成交）
• Pending Replace → Canceled（交易场所选择撤单而非改单，有时是因为成交后剩余数量不足）
• Suspended → Accepted（暂停解除，订单重新激活）
• Suspended → Expired（订单在暂停期间到期）
• Done for Day → Accepted（下一个交易日，订单重新激活）
• Done for Day → Expired（GTC 到期）

**状态持久化与恢复：**必须先将订单状态可靠地持久化（通常写入数据库或预写日志），再向订单发起方发送任何确认，或对订单执行任何操作。若 OMS 在崩溃后重启，则必须能够根据已持久化的状态以及恢复期间从执行场所收到的消息，重建每个活动订单的当前状态。这需要以幂等方式处理消息（处理重复的执行报告而不重复计入成交量），并通过查询交易场所的订单状态来进行状态核对。

订单类型

订单类型定义了订单与市场交互时遵循的执行指令。

• 市价单： 以当前最佳可用价格立即执行。在流动性充足的市场中可保证成交，但不保证价格。适用于需要紧急执行的情况。风险：在波动较大或流动性不足的市场中可能发生滑点；成交价格可能与最新报价相差很大。
• 限价单： 以指定价格或更优价格执行（买入时，价格等于或低于限价；卖出时，价格等于或高于限价）。可保证价格，但不保证成交。适用于价格控制比成交确定性更重要的情况。风险：如果市场价格未达到限价，订单可能无法成交；部分成交可能导致仓位仍有剩余。
• 止损单（止损）： 达到或穿过止损价时转为市价单。用于限制损失或保护现有仓位的利润。风险：触发后，订单会作为市价单执行；在跳空或波动较大的市场中，成交价格可能远差于止损价。
• 止损限价单： 达到止损价时转为限价单（而非市价单）。止损价用于触发订单；限价用于控制执行价格。相比止损单，能提供更多价格保护。风险：如果市场跳空穿过限价，订单可能已触发但无法成交。
• 跟踪止损单： 一种止损单，其止损价会随市场朝有利方向变动而自动调整。止损价设为低于（卖出时）或高于（买入时）市场价格的固定金额或百分比。市场朝有利方向变动时，止损价会跟随市场；市场反向变动达到跟踪幅度时，止损单便会触发。风险：触发后与止损单相同；此外，还必须校准跟踪幅度，以避免因市场正常波动而触发。
• 收盘市价单（MOC）： 按收盘集合竞价价格执行。用于跟踪基准的策略和日终投资组合调整。交易所会规定 MOC 订单的截止时间（NYSE：美东时间下午 3:50）。风险：无法控制价格；收盘集合竞价价格可能波动较大。
• 收盘限价单（LOC）： 仅当收盘价达到或优于指定限价时，才按收盘集合竞价价格执行。可为以收盘价为目标的执行提供价格保护。风险：如果收盘价高于限价，订单可能无法成交。
• 挂钩订单： 订单价格挂钩至参考价格（通常为 NBBO 中间价、最佳买价或最佳卖价），并随参考价格变动自动调整。用于算法交易和机构交易，以被动方式跟随市场。具体行为因交易场所而异。
• 冰山单（隐藏数量订单）： 订单总数量中只有一部分显示在订单簿上，其余部分隐藏（即“储备”数量）。显示数量成交后，储备数量中的额外份额会补充到订单簿上。通过隐藏完整订单规模来尽量降低大额订单对市场的影响。风险：经验丰富的参与者可能识别出冰山单模式；并非所有交易场所都支持储备订单。

有效时长指令

有效时长（TIF）指令用于指定订单在自动取消或到期前保持有效的时长。

• **DAY：**订单仅在当前交易日有效。如果在收盘时仍未成交，则会被取消。这是大多数交易场所和订单管理系统的默认 TIF。隔夜风险：DAY 订单不会延续到下一个交易日；如果投资顾问打算继续保留该订单，则必须在下一个交易日重新提交。
• **GTC（撤销前有效）：**订单将持续有效，直到发起方明确取消，或达到交易场所规定的最长 GTC 时长（通常为 60 至 90 个日历日，视交易场所而定）。GTC 订单会在收盘后继续保留，并在每个交易日重新激活。风险：过时的 GTC 订单可能会以不再符合当前投资逻辑的价格成交；公司必须制定 GTC 订单审查流程，定期重新评估未结 GTC 订单。
• **IOC（立即成交或取消）：**订单必须立即全部或部分成交。任何未能立即成交的部分都会被取消。IOC 订单不会留在订单簿上。适用于主动获取流动性的策略：交易员希望与当前可用流动性成交，而不挂出被动订单。
• **FOK（全部成交或立即取消）：**订单必须立即全部成交，否则整笔订单都会被取消。不接受部分成交。限制比 IOC 更多。适用于不能接受部分执行的情况，例如必须完全抵消风险头寸的对冲交易。
• **GTD（指定日期前有效）：**订单将持续有效，直到指定日期或被取消。其行为与 GTC 类似，但设有明确的到期日。适用于与特定事件或截止日期相关的订单。
• **OPG（开盘时）：**订单仅参与开盘集合竞价。如果在开盘过程中未成交，则会被取消。当开盘价是期望的执行基准时使用。
• **CLO（收盘时）：**订单参与收盘集合竞价。功能上类似于 MOC，但它是以有效时长指令而非订单类型的形式表达。不同交易场所的实现方式有所不同。

**收盘时的行为：**DAY 订单会被取消。GTC 和 GTD 订单会转为当日有效结束状态，并在下一个交易日重新激活。根据定义，IOC 和 FOK 订单在收盘前就已成交或取消。MOC 和 LOC 订单会在收盘集合竞价期间执行。OMS 必须在日终状态转换时正确处理每种 TIF，包括为到期的 DAY 订单生成相应的取消确认，并更新多日订单的状态。

**隔夜处理：**处于当日有效结束状态的 GTC 订单必须在下一个交易日重新提交至交易场所或重新激活。一些交易场所原生支持保留 GTC 订单；其他交易场所则要求 OMS 每天早上重新提交。OMS 必须跟踪哪些 GTC 订单需要重新提交，并将重新提交流程纳入日初工作流。

FIX 协议基础知识

金融信息交换（FIX）协议是电子交易通信的主流标准。要构建或接入任何执行场所、经纪商或交易对手方，了解 FIX 都至关重要。

订单流中的 FIX 消息类型：

• NewOrderSingle (MsgType=D)： 向执行场所提交新订单。包含所有订单参数：标的、买卖方向、数量、订单类型、价格、有效时间和账户。
• ExecutionReport (MsgType=8)： 执行场所的主要响应消息。用于确认新订单（ExecType=New）、报告成交（ExecType=Trade 或 ExecType=Fill）、报告部分成交（ExecType=Trade 且剩余数量 > 0）、确认撤单（ExecType=Canceled）、确认改单（ExecType=Replaced）、报告拒单（ExecType=Rejected）和报告过期（ExecType=Expired）。ExecutionReport 是 FIX 订单流中最重要的消息，驱动 OMS 中的所有状态转换。
• OrderCancelRequest (MsgType=F)： 请求撤销先前提交的订单。包含 OrigClOrdID（要撤销订单的 ClOrdID）以及一个用于撤单请求本身的新 ClOrdID。
• OrderCancelReplaceRequest (MsgType=G)： 请求修改先前提交的订单（价格、数量或其他参数）。包含 OrigClOrdID 和一个新的 ClOrdID。执行场所会将其视为撤销原订单并接受一个条款经修订的新订单；如有可能，这两个操作会以原子方式完成。
• OrderCancelReject (MsgType=9)： 当撤单或改单请求无法获准时，执行场所返回的响应。常见原因包括：订单已全部成交、订单已撤销，或订单处于不允许撤销的状态（例如，在停牌期间被暂停）。

关键 FIX 标签： 驱动 OMS 状态的标签包括：用于订单识别和关联的 ClOrdID (11) / OrderID (37) / OrigClOrdID (41)，用于状态转换的 OrdStatus (39) 和 ExecType (150)，以及用于成交量核算的 CumQty (14) / LeavesQty (151) / AvgPx (6)。应以执行场所提供的 LeavesQty 为准，不要自行计算剩余数量，因为部分成交和改单后两者可能不一致。

FIX 会话层与应用层： FIX 分为两层：会话层（连接管理、心跳、序列号、缺口恢复）和应用层（订单、执行、撤单——本技能的主题）。会话层管理由交易所连接技能（trading-operations）负责；会话中断后，必须先在那里重新连接并协调序列号，才能恢复应用层消息传递。

FIX 版本： FIX 4.2 仍被广泛部署，是许多执行场所的基线版本。FIX 4.4 增加了多项改进，包括更好地支持多腿订单和分配消息。FIX 5.0 引入了 FIXT 传输层（将会话协议与应用协议分离），并增加了对市场数据和交易后消息的支持。连接新的执行场所时，请确认其支持的 FIX 版本以及消息扩展（如有）。

取消和替换工作流

取消和替换工作流是订单生命周期管理中对操作要求最严格的环节之一。它们涉及并发状态变更、竞态条件，以及可能出现的意外结果。

取消请求流程：

1. OMS 向交易场所发送 OrderCancelRequest（MsgType=F），引用要取消订单的 OrigClOrdID，并为取消请求分配新的 ClOrdID。
2. 订单在 OMS 中转为 Pending Cancel。
3. 交易场所通过 ExecutionReport（ExecType=Canceled，OrdStatus=Canceled）确认取消，或通过 OrderCancelReject（MsgType=9）拒绝取消请求。
4. 如果取消成功，订单转为 Canceled（终态）。如果请求被拒绝，订单则恢复到之前的状态（Accepted 或 Partially Filled）。

替换（修改）请求流程：

1. OMS 向交易场所发送 OrderCancelReplaceRequest（MsgType=G），引用 OrigClOrdID，并提供修改后的订单参数（新价格、新数量或两者），同时分配新的 ClOrdID。
2. 订单转为 Pending Replace。
3. 交易场所通过 ExecutionReport（ExecType=Replaced，OrdStatus=Replaced）确认替换，或通过 OrderCancelReject 拒绝请求。
4. 如果替换成功，原订单转为 Replaced（终态），OMS 中会创建一个带有修改后参数和新 ClOrdID 的新订单。如果请求被拒绝，原订单则恢复到之前的状态。

竞态条件——取消与成交： 最关键的竞态条件发生在取消请求与成交同时在途时。OMS 发送取消请求后，交易场所在处理该请求前，订单可能已全部或部分成交。交易场所可能先发送成交 ExecutionReport，再发送 OrderCancelReject（因为订单此时已成交，无法取消）；如果只发生部分成交且剩余数量已取消，也可能同时发送成交确认和取消确认。OMS 必须处理所有可能的消息顺序：

• 先收到成交，再收到 CancelReject：订单已成交，取消请求已无意义。
• 先收到 CancelReject，再收到成交：OMS 在处理成交前，不得将订单从 Pending Cancel 恢复到之前的状态。消息顺序很重要。
• 部分成交并收到取消确认：取消生效前订单已部分成交。部分成交仍然有效；剩余数量已取消。

订单链（ClOrdID 与 OrigClOrdID 的关联）： 每次取消或替换都会在订单链中创建新的链接。原始订单的 ClOrdID 为 A。替换请求引用 OrigClOrdID=A，并分配 ClOrdID=B。之后的替换请求引用 OrigClOrdID=B，并分配 ClOrdID=C。OMS 必须维护这条链，以正确关联属于同一逻辑订单的所有消息。如果链条断开，例如引用了错误的 OrigClOrdID，交易场所就会拒绝请求，甚至可能取消或替换错误的订单。

待处理状态规范： 当订单处于 Pending Cancel 或 Pending Replace 状态时，OMS 不应针对同一订单提交其他取消或替换请求。并发提交取消或替换请求会造成歧义，无法确定交易场所正在处理哪个请求，并可能导致意外结果。在待处理请求得到解决之前，应将新的取消或替换意图排队。

订单验证

订单验证是指在订单提交到执行场所之前进行的一系列检查。全面的验证可以及早发现错误，避免订单被执行场所拒绝，并确保遵守风险管理和合规要求。

提交前验证（OMS 级别）：

• 购买力／保证金检查： 验证账户是否有足够的现金或保证金来支付订单。对于买入订单，检查可用现金或购买力。对于卖空订单，检查保证金是否充足以及是否符合借券要求（Reg SHO）。
• 持仓限额： 验证订单是否会导致账户（或公司汇总持仓）超过持仓限额，包括监管限额（交易所针对期权和期货规定的持仓限额）或内部限额（风险管理限额）。
• 限制名单筛查： 检查证券是否在公司的限制名单上。限制证券的订单会被直接拦截。这是法律和合规要求，旨在防止利用重大非公开信息进行交易。
• 市场时段验证： 验证订单是否在该执行场所和证券的适当市场时段内提交。盘前和盘后订单必须符合明确的资格要求，且可能仅支持某些订单类型（通常为限价订单）。
• 证券代码验证： 验证证券标识符（股票代码、CUSIP、ISIN、SEDOL）是否有效，以及是否对应目标执行场所中有效且可交易的证券。
• 手数验证： 验证订单数量是否符合执行场所的手数要求（整手、零股或混合手数）。有些执行场所会拒绝零股订单，或以不同方式路由此类订单。
• 价格合理性： 对于限价订单，检查限价是否处于当前市场价格的合理范围内。以当前价格 10 倍的价格买入，可能是操作错误。可配置的阈值（例如，限价必须在最近成交价的 10% 以内）有助于发现误操作。
• 重复订单检测： 检查同一账户和证券近期是否已提交相同或近似的订单。重复订单可能意味着录入错误。

交易所级别验证： 即使通过 OMS 验证，交易所也会执行自己的检查：证券代码是否适用于该执行场所、订单类型是否受该执行场所支持、价格是否处于该执行场所的价格区间（涨跌停范围）、数量是否未超过该执行场所的最大订单规模，以及参与者是否具备相应权限。交易所拒绝订单时，会返回 FIX Reject 或 ExecType=Rejected 的 ExecutionReport，并附上原因代码。

拒绝处理和错误代码： 订单被拒绝时，无论拒绝方是 OMS 还是执行场所，都必须记录并保存拒绝原因，并告知订单发起方。FIX Tag 103 (OrdRejReason) 提供标准化的拒绝代码：经纪商／交易所选项（0）、未知证券代码（1）、交易所已关闭（2）、订单超出限额（3）、提交时间过晚（4）、未知订单（5）、重复订单（6）等。OMS 应将执行场所特定的拒绝代码映射为便于交易员和运营人员采取行动的错误消息。

多腿订单与条件订单

交易系统必须支持涉及多个腿或条件执行逻辑的订单。

• OCO（One Cancels Other，一单取消另一单）： 两个订单相互关联，当其中一个订单成交（或部分成交）时，另一个订单会自动取消。常见用例：为现有持仓设置止盈限价单和止损单。当一个订单触发后，另一个订单便不再需要。OMS 必须监控这两个订单，并在其中一个订单成交后发起取消另一个未成交订单的操作。
• 括号订单： 由三部分组成：入场订单、止盈订单和止损订单。只有在入场订单成交后，才会提交止盈订单和止损订单，并将它们组成 OCO 订单对。括号订单需要 OMS 执行条件逻辑——子订单取决于父订单的状态。
• 条件订单： 仅在满足指定条件时才会激活的订单。例如，“如果 S&P 500 跌破 4,000，则提交一笔 AAPL 的 150 美元买入限价单。”OMS 必须实时监控条件，并在条件触发时提交订单。
• 订单列表： 一组一并提交、采用指定执行策略的订单（例如，列表中的订单全部成交或全部不成交、按顺序执行或独立执行）。FIX 通过 NewOrderList（MsgType=E）消息支持订单列表消息传递。
• 父子关系： 复杂订单结构，其中父订单在执行时生成子订单。例如，一笔 10,000 股的父买入订单可能会根据智能订单路由策略，生成多个路由至不同交易场所的子订单。OMS 必须跟踪父订单与子订单之间的关系，并汇总子订单的成交情况以更新父订单状态。

订单审计轨迹

法规要求对所有订单活动进行全面审计跟踪。

综合审计跟踪（CAT）： CAT 取代了 FINRA 的 OATS（Order Audit Trail System，订单审计跟踪系统），要求经纪交易商和某些其他参与者报告 NMS 证券及上市期权每笔订单的详细生命周期事件。需报告的事件包括订单接收、订单发起、订单路由、订单修改（取消/替换）、订单执行和订单取消。CAT 要求在订单发起时识别客户，使监管机构能够跨越所有交易场所和中介机构，追踪每笔订单从发起到执行或取消的全过程。

时间戳精度： CAT 要求时间戳至少达到毫秒精度，许多公司还会采集微秒或纳秒精度的数据，用于内部分析和合规。订单流中所有系统的时钟同步至关重要——FINRA Rule 4590 要求时钟同步误差在规定范围内（通常，手动事件为 1 秒，电子事件为 50 毫秒）。OMS、FIX 网关和执行交易场所之间的时间戳漂移可能导致审计轨迹不一致，且难以解决。

订单事件日志： 每次状态转换、发送的每条消息和接收的每条消息都必须记录时间戳、消息内容（或关键字段）以及处理该事件的系统组件。日志必须不可篡改——创建后不得修改或删除条目。此事件日志是法规报告、争议解决和运营取证的基础。

重建能力： 监管机构可能会要求按特定时间段、证券、账户或交易员，完整重建订单活动。审计轨迹必须支持任意粒度的重建：单笔订单的完整生命周期、某个交易时段内某种证券的所有订单，或特定交易台或个人发起的所有订单。重建需要关联 OMS 记录、FIX 消息日志、执行交易场所报告以及清算/结算记录。

实例详解

references/examples.md 中有三个实例详解——加载该文件以查看端到端场景：（1）为经纪交易商的 OMS 设计订单状态机；（2）实现撤单/替换工作流并处理竞态条件；（3）将 FIX 连接集成到新的执行场所（会话层细节请参见 exchange-connectivity）。

常见陷阱

• 将状态机实现为拒绝列表（阻止特定状态转换），而非允许列表（仅允许明确定义的状态转换）——拒绝列表方法会悄无声息地放过新的无效状态转换
• 未处理撤单与成交之间的竞态条件，导致订单处于 PendingCancel 状态时收到成交 ExecutionReport，成交信息却被丢弃
• 在场所确认替换前就乐观地更新 ClOrdID，导致后续请求引用场所无法识别的 ClOrdID
• 允许对同一订单并发发送撤单和替换请求，导致场所状态不明确
• 在确认或处理入站消息前未持久化订单状态，导致系统重启时状态丢失
• 不慎处理 FIX 序列号——跳过缺口填补处理，或未经双方同意就重置序列号，都会导致消息丢失
• 忽略 ExecutionReport 中的 LeavesQty 并自行计算剩余数量，部分成交和替换后可能导致计算结果与场所记录不一致
• 实现 GTC 订单却没有定期审核流程，导致过时的限价订单以不再符合投资论点的价格成交
• 仅在场所验证订单（依赖交易所拒绝），而不在 OMS 中预先验证，这会提高拒绝率并增加往返延迟
• 假设所有场所对 FIX 的实现都完全相同——每个场所都有不同的解释、自定义标签和特定的消息流行为，必须在认证期间逐一确认
• 记录订单事件时未提供足够精度的时间戳或未同步时钟，导致审计记录无法满足监管重建要求
• 未实现幂等消息处理，导致重复的 ExecutionReport（FIX 会话恢复期间很常见）重复计算成交量并破坏头寸跟踪
• 未强制终态不可变，导致应用程序错误将订单从 Filled、Canceled 或 Rejected 状态中转出

交叉引用

• trade-execution（trading-operations 插件）：执行算法、交易场所选择、智能订单路由和市场微观结构，这些因素决定订单离开 OMS 后的执行方式。
• pre-trade-compliance（trading-operations 插件）：限制订单提交的合规检查，包括限制名单筛查、持仓限额，以及整合到订单验证工作流中的监管约束。
• post-trade-compliance（trading-operations 插件）：执行后的合规监控，包括交易监控、最佳执行分析，以及使用订单生命周期数据的异常报告。
• settlement-clearing（trading-operations 插件）：订单执行后的下游流程，包括交易匹配、通过 CCP 或双边净额结算进行清算，以及证券和现金结算，从而完成订单生命周期。
• order-management-advisor（advisory-practice 插件）：面向顾问的订单管理，涵盖大宗交易、分配、模型驱动交易和托管机构路由，并以此处定义的订单生命周期概念为基础。
• exchange-connectivity（trading-operations 插件）：连接交易所和执行场所的技术基础设施，包括 FIX 引擎配置、网络架构和故障转移设计。
• books-and-records（compliance 插件）：SEC Rules 17a-3/17a-4 和 Rule 204-2 规定的记录保存要求，涉及保留订单票据、执行记录，以及整个订单生命周期中生成的审计跟踪数据。