4. 执行风险识别：滑点与交易成本、订单执行延迟、交易所故障与网络延迟
做价差回归交易，策略逻辑再漂亮，信号抓得再准，最后都得落到「执行」这两个字上。我见过太多人，回测曲线画得跟教科书一样漂亮，一上实盘就亏得亲妈都不认识。为什么？说白了，就是执行风险没管好。
这一节，咱们就聊聊执行层面的三个「隐形杀手」：滑点与交易成本、订单执行延迟、以及交易所故障与网络延迟。嗯，每一个我都踩过坑，今天一并倒给你们。
4.1 滑点与交易成本：你以为的成交价，不是真的成交价
先问个问题：你回测时用的成交价是什么？是收盘价？还是当时的卖一价？
如果你用的是收盘价，那我可以负责任地告诉你——你的回测大概率是「美化版」。真实世界里，你下买单时，看到的可能是卖一价，但等你订单飞过去，卖一可能已经被别人抢了，你只能吃卖二、卖三。这一来一回的差价，就是滑点。
滑点是怎么产生的？
- 市场流动性不足：你做的价差品种如果本身交易量不大，挂单稀疏，稍微大一点的单子就能把价格打穿。我在做某些商品期货跨期套利时遇到过，一个单子下去，盘口直接跳了两跳，滑点吃掉了我一半的利润。
- 市场波动剧烈：数据发布、突发事件时，价格跳动极快。你看到的报价，等你下单时已经过时了。这叫做「报价延迟」导致的滑点。
- 订单簿结构：如果买一和买二之间价差很大，你的订单一旦吃掉买一，就得承受更大的滑点。
核心观点：滑点不是偶然事件，它是交易成本的一部分。你必须把它纳入你的策略预期中，而不是事后懊恼。
交易成本不只是佣金
很多人只盯着手续费，觉得万分之一、万分之二无所谓。但你想想看，价差回归策略本身赚的就是微薄的价差，如果双边手续费加上滑点，可能一次交易下来，利润全交了「过路费」。
我习惯把交易成本拆成三块：
| 成本类型 | 说明 | 典型范围 |
|---|---|---|
| 显性成本 | 佣金、印花税、过户费等 | 万分之一 ~ 万分之三 |
| 隐性成本 | 滑点、市场冲击 | 0.1 ~ 2 个 tick |
| 机会成本 | 未成交导致的价差损失 | 难以量化，但真实存在 |
我的习惯：在回测中，我会强制加上一个「保守滑点」——比如双边各加 0.5 个 tick。如果这样跑下来策略还能赚钱，那实盘才有戏。如果回测刚好在盈亏边缘，那实盘大概率是亏的。
4.2 订单执行延迟：你的信号，可能已经过期了
做价差交易，最怕什么？最怕你看到价差偏离了，下单买入，结果等订单成交时，价差已经回归了。你不仅没赚到钱，反而买在了高点。
这就是订单执行延迟的问题。
延迟从哪里来？
- 策略计算延迟：你的策略代码跑得慢。比如你用 Python 写了个复杂的统计模型，每次信号计算要 50 毫秒。这 50 毫秒里，市场可能已经变了。
- 网络传输延迟：从你的服务器到交易所的撮合引擎，数据包要走光纤。物理距离越远，延迟越大。上海到芝加哥，来回至少 200 毫秒。
- 交易所处理延迟：订单到达交易所后，要排队、要撮合。如果交易所系统负载高，处理时间会变长。
- 订单类型选择：你用限价单还是市价单？限价单可能一直挂在那里不成交，市价单虽然成交快，但滑点大。
我曾经做过一个跨交易所的价差策略，一个合约在郑商所，一个在大商所。两个交易所的撮合速度不一样，网络延迟也不一样。结果就是，我这边信号出来了，但两个订单到达时间差了 100 多毫秒。这 100 毫秒里，价差已经变了，我等于在追涨杀跌。
避坑指南：我曾经以为只要策略逻辑对，执行慢一点没关系。结果实盘一个月，滑点和延迟吃掉了策略 60% 的收益。后来我痛定思痛，把所有代码从 Python 改成了 C++，并且把服务器托管到了交易所机房旁边。延迟从 50 毫秒降到了 1 毫秒以下。效果立竿见影。
怎么量化延迟的影响？
我建议你在回测中引入一个「延迟模拟器」。比如，假设你的订单会在信号出现后 100 毫秒才成交，那么你就用 100 毫秒后的价格来计算盈亏。这样你就能知道，你的策略对延迟有多敏感。
# 伪代码示例：延迟模拟
def simulate_delay(signal_time, delay_ms=100):
# 假设信号在 signal_time 产生
# 实际成交时间 = signal_time + delay_ms
actual_trade_time = signal_time + delay_ms
# 用 actual_trade_time 的价格计算盈亏
return get_price_at(actual_trade_time)
4.3 交易所故障与网络延迟：黑天鹅中的黑天鹅
这部分，我希望你永远用不上，但你必须知道。
交易所也是系统，系统就会出故障。我经历过几次：
- 交易所宕机：某次，某主流交易所因为系统升级出问题，直接停了 30 分钟。我的策略还在运行，订单全部被拒。等交易所恢复时，价差已经面目全非。
- 网络中断：服务器到交易所的网络专线断了。虽然概率极低，但一旦发生，你的订单就飞不出去了。
- 数据源异常：行情数据突然卡住，或者出现错误数据。你的策略如果没做数据校验，可能会根据错误数据下单，那后果不堪设想。
我的应对方案：
- 多数据源备份：至少接入两个不同的行情数据源。如果一个数据源异常，自动切换到另一个。
- 订单超时机制：每个订单设置一个最大等待时间。如果超过这个时间还没成交，就撤单重发，或者直接放弃这次交易。
- 手动熔断：当检测到连续多次订单被拒，或者网络延迟超过阈值时，自动停止策略，并发送报警给运维人员。
- 灾备方案：主服务器和备用服务器部署在不同的机房。如果主服务器挂了，备用服务器能无缝接管。
网络延迟的监控
我习惯在系统里加一个「心跳监控」。每隔 1 秒，向交易所发送一个 ping 包，记录往返时间。如果连续 3 次 ping 的延迟超过 500 毫秒，我就认为网络有问题，自动降低交易频率，甚至暂停交易。
一个小技巧：不要只监控平均延迟，还要监控延迟的「抖动」。有时候平均延迟只有 10 毫秒，但偶尔会跳到 500 毫秒。这种抖动对高频价差交易来说，比稳定的高延迟更致命。因为它不可预测。
知识体系总览
下面这张图，是我自己梳理的执行风险识别框架。你可以把它当作一个检查清单，每次上线新策略前，逐条核对。
好了，执行风险这块，咱们就聊到这儿。记住一句话：策略是子弹，执行是枪。枪不好使，子弹再准也打不中目标。下一节，咱们聊聊怎么用「仓位管理」来对冲这些执行风险。