行情接入与入库：tick 与 K 线回填，以及演示数据降级
做量化平台，最容易被低估的一件事是：数据不是“有就行”。
在真实团队里，策略交付失败很多时候不是策略写错了，而是数据链路不稳定、口径不一致、缺少降级方案。
结论先行：EasyQuant 把行情链路拆成两条可组合的管线，并提供演示数据/模拟数据的降级能力，保证 research / paper / backtest 的最短闭环始终可跑通：
- 实时管线：tick（WS）→ 入库 → 驱动策略评估/执行
- 回测与评估管线：1m bars（REST 回填/批量入库）→ 回测输入基石
一、为什么必须同时要 tick 与 bars？
很多系统只做一种数据：要么只做 tick，要么只做 K 线。
但在平台视角里，它们承担不同职责：
- tick：用于实时状态与最新价、驱动 paper/准生产的“事件触发”
- bars（尤其 1m）：用于策略指标计算、回测输入、以及跨策略的口径统一
如果你只靠 tick 生成 bars，链路会更复杂；
如果你只靠 bars 做实时，延迟与实时性会受限。
所以 EasyQuant 的策略是：两条管线都支持，但保持口径统一、并允许降级。
二、平台级需求：你必须回答的 4 个数据问题
行情链路是否“可交付”，不看你接了多少数据源，而看你能否稳定回答：
- 新鲜度：最新 bars/tick 到底更新到什么时候？是否滞后？
- 完整性：区间内 bars 是否缺口？是否有异常时间戳？
- 一致性：回测与 paper 是否使用同一口径的 bars（交易时段过滤/时区）？
- 可降级：外部行情不可用时，能否用演示/模拟数据跑通闭环？
这四点最终决定了：你能否解释“为什么没信号/没下单”（见 03），以及结果是否可复现（见 04）。
三、K 线回填：把回测输入做成确定性的基础设施
对 backtest 来说，最关键的是：回测输入要稳定、可重复读取。
因此 EasyQuant 强调：
- 1m bars 作为回测输入基石（后续可扩展到 5m/15m/日线）
- 回填与入库是一个明确的动作（而不是临时在线抓取）
- 回测服务只做“读取与模拟”，不把外部不确定性带进来
你在产品上看到的直接价值
- 同一时间窗可以重复回测并对比
- 能明确判断“无成交”是否因为缺 bars（NO_BARS）
- 能对 bars 做交易时段过滤，避免非交易时段噪声影响指标
四、tick 入库：让 paper/准生产链路可演进
tick 的价值在于：
- 让系统具有“实时感”（最新价、最新成交、最新事件）
- 让 paper 执行链路更接近真实运行：有触发、有状态、有事件
但 tick 管线也更容易遇到不可控问题（断线、订阅失败、权限问题）。
因此平台必须具备“降级策略”，否则 demo/联调/试点会频繁卡住。
五、演示数据降级：保证最短闭环永远可跑通
如果外部行情暂不可用（或你不希望把演示依赖在外部），EasyQuant 推荐的做法是：
- 用系统运维/系统状态页的一键演示能力写入 demo 数据
- 用模拟 bars/ticks 生成可交易的走势形态
- 让回测中心与图表功能在无外部依赖的情况下可演示、可验收
这件事看起来“只是 demo”，但它决定了：
- 新人 onboarding 是否顺滑
- CI/回归是否可控
- 产品演示是否稳定
本质上，它是在把“环境不确定性”从产品体验里剥离出去。
六、排障：当你遇到“无数据/数据不新鲜”
把排障按成本排序：
- 系统健康检查（后端 UP）
- 查询最近 bars 是否存在（缺 bars 就先解决 NO_BARS）
- 检查交易时段过滤是否把数据过滤没了
- 外部行情不可用时，先用演示数据跑通再定位外部问题
相关的排障 checklist 与常用 API 速查见：docs/HELP_CENTER.md。
结语：数据链路决定了平台的“交付下限”
策略再好，数据不稳定就交付不出去；
数据口径不一致，回测与 paper 就无法对齐；
缺少降级方案，demo 与试点就会频繁失败。
下一篇（06）我们会继续把“口径统一”讲透：从 1m 到策略周期的聚合，以及为什么必须做交易时段过滤。