数据源三级 fallback：BaoStock 5min→daily→腾讯分钟线，做T成交验证不再裸奔

盯盘时信号明明触发了，成交回报却迟迟对不上。查日志才发现，凌晨两点的数据拉取接口直接抛了 429 异常，整个做 T 的成交验证模块瞬间裸奔。做日内交易最怕的不是策略失效，而是数据断档。你以为在复盘，其实只是在盲猜。后来我花了三天时间，把单一数据源砍掉，改成了 BaoStock 5 分钟线优先、日线兜底、腾讯分钟线补位的三级 fallback 架构。跑了一个月，成交校验准确率稳稳压在 99.2% 以上。

数据拉取入口怎么收口

数据源切换必须统一收口，不能让策略层感知到底层在换血。

我在核心链路顶部建了一个 fetch_trade_data 函数。所有行情请求只走这一个出口。第一层直接请求 BaoStock 的 5 分钟 K 线。接口返回正常且数据行数大于阈值，直接入库校验。触发 429 限流或网络超时，立刻降级到第二层。第二层拉取 BaoStock 的日线数据，通过复权因子和日内波动假设，拼接出近似分钟线。日线颗粒度太粗，只能验证成交方向和大体价位。遇到长假前后数据稀疏，或者日线接口也挂了，直接切第三层。第三层走腾讯财经的分钟线接口，走 HTTP 直接拿 JSON。三套数据格式完全不同，统一清洗成标准 OHLCV 字典再入库。校验模块只认标准格式，底层怎么换它根本不知道。

格式清洗管道怎么搭

降级逻辑写起来简单，对齐数据格式能掉一层皮。BaoStock 返回的是 DataFrame，列名是 date, open, high, low, close, volume。腾讯接口返回的是嵌套 JSON，时间字段叫 time，成交量叫 vol。我把所有源的数据塞进同一个清洗管道，统一重命名列。转换时间戳为 UTC 毫秒，方便后续跨表关联。

清洗管道必须是无状态的。每次传入原始数据，输出标准化字典列表。遇到缺失字段直接补零，不抛异常中断流水线。字段类型强制转换，字符串转浮点，空值转 NaN。管道里塞了三个校验节点，分别检查列完整性、数值范围和日期合法性。任何一个节点不通过，数据直接进脏数据队列，人工排查。这样能保证下游验证逻辑永远拿到干净的结构。

时间对齐踩过的坑

时间对齐是重灾区，直接按字符串匹配会丢最后一笔。BaoStock 的 5 分钟线收盘时间带的是当天日期。腾讯分钟线在跨日交易时段会带上次日标记。做 T 验证时，尾盘最后一笔经常对不上。我改用 pd.to_datetime 统一解析，再按交易日历过滤非交易日。遇到停牌股票，三级接口全返回空数组。这时候 fallback 不能无限重试，直接打日志标记 skip，避免死循环拖垮主线程。

时间戳对齐还要处理时区漂移。服务器默认跑在 UTC，但交易接口返回的是本地时间。我在入库前统一乘 1000 转毫秒，去掉时区干扰。校验模块比对委托时间和成交时间时，只看毫秒差值。超过两秒的偏差直接打标记，不阻断主流程。这样既保留了精度，又给了容错空间。

成交验证怎么分级

三级 fallback 不是为了让数据完美，而是为了在残缺状态下依然能验证。5 分钟线能精确到笔，适合高频做 T。日线兜底时，只能确认当天是否发生同向交易。我把验证逻辑拆成两个阶段。强校验跑在 5 分钟线上，比对委托价和成交价误差在 0.1% 以内。弱校验跑在日线或腾讯线上，只核对成交量方向和大致区间。

强校验失败会触发二次比对。系统自动拉取券商 API 的逐笔成交，做交叉验证。弱校验失败只记录告警，不阻断交易流。腾讯分钟线虽然免费，但频率限制严，单只股票每分钟只能拉一次。我在请求头里加了随机延迟，避开整点并发高峰。数据源切换时，模块内部会自动记录 fallback 层级。跑批脚本每天生成一份数据质量报告，标记哪些票走了降级路径。看到降级率突然飙升，就能提前排查接口状态。

降级监控怎么落地

数据容错设计从来不是追求理论完美。市场接口随时可能抽风，策略代码再漂亮也扛不住底层断流。把 fallback 写进核心链路，相当于给做 T 验证穿了件隐形防弹衣。下次再遇到限流或断档，日志只会多一条降级记录，不会多一个爆仓借口。

我在监控大盘里加了三个看板。一个是数据完整度，显示三级源的成功率。一个是验证通过率，强校验和弱校验分开统计。一个是降级热力图，按股票和时段展示 fallback 触发频率。看板背后跑着定时任务，每小时聚合一次指标。阈值设得很宽，只有连续三次降级或强校验跌破 95% 才会发钉钉告警。这样既不会误报扰民，又能抓住真问题。交易系统的稳定性，往往就藏在这些不起眼的降级逻辑里。