一、套利数据底座要解决的核心：让“价差”可重复、可对账
套利能不能做成，取决于你看到的价差是不是“真实、可重复”的价差。真实意味着同一时刻的可成交价格可以对齐；可重复意味着相同条件下你能再次观察到它；可对账意味着事后能解释这次触发来自哪家交易所、哪条链路、哪种延迟与哪种清洗规则。
很多套利失败并不是模型不够聪明，而是数据底座把噪声当成信号：延迟错位、盘口深度不可比、不同交易所的时间戳口径不一致，都会制造“看起来很香”的假价差。
二、统一内部协议：先把多交易所报价写成同一种语言
多交易所报价要先统一成内部协议，否则下游每个模块都会重复解决同一组问题。建议固定最小字段集：symbol、ts（UTC 毫秒）、bid/ask、last、qty、source、ingest_ts，并用 quality 字段标记这条报价是否通过完整性校验。
symbol 的定义也要统一：同一个交易对在不同交易所的命名差异必须被消解，否则你会在对账时陷入“看起来是同一资产，实际上不是同一标的”的陷阱。内部协议稳定后，策略与监控才能真正复用。
三、时间对齐是第一优先级：先把延迟变成可度量变量
套利的价差比较，本质是比较同一时刻的两个可成交价格。所以你必须把延迟工程化：记录每条数据的 source_ts、ingest_ts、deliver_ts，并把延迟拆成采集延迟、传输延迟、处理延迟三段。没有延迟拆解，你无法判断价差来自市场还是来自系统。
更稳健的实践是建立“对齐窗口”：只在两个源都在可接受延迟范围内时才允许进入价差计算；一旦某个源延迟飙升或出现缺口，直接降级为只监控不交易。
四、盘口可比性：用深度与冲击成本过滤“不可交易价差”
套利不是比较 last，而是比较可成交的 bid/ask 与可成交规模。你至少要关注两件事：在目标下单规模下的冲击成本，以及成交后能否快速对冲。很多价差只存在于极小的盘口深度里，真实下单会把价差抹平甚至反向。
因此，价差计算建议分两层：先用顶层盘口做粗筛，再用多档深度估计冲击成本做精筛。把“可成交价差”与“报价价差”区分开，你的信号质量会大幅提升。
五、补洞与乱序处理：没有对账能力，就不要谈实盘
多源实时流一定会遇到断线、补洞、乱序与重复。你必须能回答：断线期间缺了多少数据、补洞数据是否完整、补洞数据与实时数据是否重复、以及你最终写入的序列是否严格递增。否则同一段行情在不同运行周期里会产生不同信号。
工程上建议把“最后确认处理到的序号/时间戳”写进状态，并在重连后优先补洞再恢复实时；所有写入都要幂等化，确保重复消息不会影响下游状态。
六、对账机制：把每一次触发写成可回放的证据链
套利系统必须可回放，否则你无法解释一次失败交易到底是市场原因还是数据原因。建议为每次触发记录一条证据链：两端交易所的盘口快照、延迟快照、清洗与过滤规则版本、阈值参数、以及最终的“允许交易/禁止交易”决策原因。
证据链的目标不是做漂亮日志，而是让你能在事后用同一套数据重放并得到相同结果。可回放，是套利系统最重要的护城河。
七、监控与告警：先监控数据健康，再监控策略表现
套利的告警优先级应该是数据健康度而不是收益。建议至少监控：各交易所延迟分位数、断线次数、缺口长度、乱序比例、重复比例、以及价差分布的突变。价差分布突变往往意味着某个源异常或口径变化，而不是突然出现“免费午餐”。
告警动作也要规则化：延迟异常触发降级，缺口扩大触发暂停交易，价差分布异常触发切源或提高阈值。能自动保护自己，比能捕捉一次机会更重要。
八、成本与限流：订阅分层与降采样是长期运行的关键
多交易所高频数据的成本主要来自订阅规模与计算开销。建议把订阅分层：核心交易对高频订阅用于策略与风控，长尾交易对低频订阅用于面板与研究。下游拥塞时优先降采样与聚合，而不是盲目扩容。
同时要把限流与退避写成标准库：一旦某个交易所触发限流，系统必须自动降低请求频率并保留对账能力，避免在压力时刻把自己打崩。
九、把底座连接到策略：从“发现价差”到“可执行交易”
数据底座的终点不是输出一条价差曲线，而是为执行提供约束：什么时候允许下单、下单规模上限是多少、对冲是否可用、以及在压力态如何快速退出。建议把策略输出限定为“意图”，执行模块根据当前深度与延迟决定市价/限价/放弃，并把滑点与失败原因写入证据链。
这样你才能把系统做成长期迭代：问题来自数据、执行还是策略，会在日志里清晰分层，而不是混成一团。
十、结语：套利系统的优势来自“可对账”，不是“看起来聪明”
真正可靠的套利系统，首先是一套高质量数据系统：口径统一、延迟可度量、可回放可对账、可监控可降级。只要底座足够稳健，你的策略空间才会逐步打开；反之，底座不稳，任何聪明信号都只能停留在回测或偶然。
把数据底座做成资产，你会发现：套利不再是一次性机会，而是一条可持续优化的工程链路。
如果你只做一件加法，建议把“证据链”做成默认产物：每一次价差触发都能被回放、被解释、被复核。只要证据链稳定，后续无论是扩交易所、扩交易对、还是引入更复杂的执行与风控，你都能在同一套对账框架里迭代，而不是在噪声里猜。
