选套餐时最容易犯的错误，是默认「实时一定比延迟好」。事实上，很多团队每月多付几百美元买来的实时数据，用在了根本不需要实时的场景上；而另一些团队为了省钱选了延迟套餐，结果核心功能不可用。
判断标准不应该是「哪个更高级」，而应该是你的业务决策周期有多长。
「延迟」到底意味着什么
延迟行情指的是数据不是随市场变化即时下发，而是经过一段时间后才可用。它与你熟悉的「实时行情」在数据结构上完全一致——同样的字段、同样的接口、同样的格式，区别只在时效性。
这一点很重要，因为它意味着：从延迟切换到实时，不需要改代码结构，只需要改套餐权限。 这也让「先用延迟开发、上线前再升级」成为一种可行的策略。
怎么在代码里判断拿到的是不是延迟数据
不要靠假设，要靠字段。行情接口的响应里带有 delayed 布尔字段，为 true 时表示该数据当前是延迟的：
import httpx
resp = httpx.get(
"https://api.tiqex.io/api/v1/market/quote",
params={"codes": "AAPL,EURUSD,BTCUSDT"}, # 单次最多 50 个 codes
headers={"X-API-Key": "your_api_key"},
timeout=10,
)
body = resp.json()
for row in body["data"]:
flag = "延迟" if row.get("delayed") else "实时"
if row.get("unavailable"):
flag = "不可用"
print(f"{row['code']:<10} {flag} last={row.get('last')}")
把 delayed 与 unavailable 都纳入判断，可以避免一个常见事故：开发环境用免费套餐跑通，生产环境上线后发现某些市场其实是延迟的，而代码里没有任何校验。 建议在应用启动时做一次自检，把各市场的实时/延迟状态打印出来，或直接对关键市场断言必须为实时。
延迟数据足够用的四类场景
- 历史数据分析与可视化：只要数据最终一致，用于图表、报表、趋势分析时延迟完全不影响结论。
- 低频策略与再平衡：按日或按周调仓的策略，决策周期以天计，秒级延迟毫无意义。
- 组合估值与风险快照：每日收盘后的估值、持仓核对、风险敞口计算，用延迟数据即可。
- 开发与测试：接口联调、单元测试、CI 流水线验证，延迟数据完全够用，而且免费。
必须用实时数据的三类场景
- 交易执行与下单决策：价格是决策的直接输入，延迟意味着按过时价格成交。
- 实时告警与风控：止损提醒、异常波动告警、风险阈值触发，延迟会让告警失去意义。
- 面向用户的实时界面：交易终端、行情看板、投研工具。用户能直接看到价格在跳，延迟数据会造成明显的体验落差和信任问题。
这三类的共同点是：延迟直接改变了决策结果或用户感知。只要满足这一条，就必须上实时。
按场景对照套餐
| 你的场景 | 所需权限 | 参考套餐 |
|---|---|---|
| 接口联调、原型验证 | 延迟即可 | Free |
| 历史数据回填与报表 | 延迟即可 | Free / Growth |
| 加密与金属的实时监控 | 实时（部分市场） | Growth |
| 跨市场实时看板（股票 + 外汇 + 加密） | 全市场实时 | Pro |
| Level 2 深度与私有连接 | 全市场 Level 2 | Enterprise |
值得注意的一点是：不同套餐的市场权限是分档的，不是简单的「全延迟 / 全实时」。某个中间档套餐可能让加密与金属实时，而股票、外汇、指数仍是延迟。所以选型时要按市场维度核对，而不是只看套餐名称。
混合方案：把实时额度花在刀刃上
如果预算有限但又有实时需求，常见的做法是混合使用：
- 关键标的走实时流式：只对需要实时决策的少数标的订阅 WebSocket。
- 其余走延迟查询：非关键标的用 REST 定期拉取延迟数据。
- 前端明确标注数据时效：延迟数据在界面上加时间戳或标识，避免用户误判。
这样既控制了成本，也避免了「全量实时」带来的额度与流量压力。需要注意 WebSocket 的订阅数量受套餐约束，选型时要一并确认。
你的策略能容忍多少延迟
一个实用的判断方法，是从决策周期反推延迟预算：
| 策略周期 | 决策频率 | 有意义的延迟量级 |
|---|---|---|
| 高频 / 做市 | 亚秒级 | 个位数毫秒 |
| 日内交易 | 秒级到分钟级 | 一秒以内 |
| 每日调仓 | 每天一次 | 分钟级 |
| 周度 / 月度配置 | 数天到数周 | 小时级 |
拿这张表对照你自己的决策频率。如果最快的决策一天只发生一次，为毫秒级数据付费就是在买你永远用不上的精度；如果最快的决策每秒都在发生，延迟数据会让系统「算错」，而不只是「慢一点」。
一个容易忽略的坑：延迟数据的缓存语义
延迟数据有个特性容易被忽略：同一时刻多次请求，返回的可能是同一个值。这意味着你在延迟模式下写的缓存逻辑，切换到实时后会失效——因为实时数据的每次请求都可能返回新值。
典型症状是：开发时缓存 60 秒看起来完全没问题，上线切实时后用户反馈「价格不动」。所以缓存策略必须与数据时效性匹配：延迟数据可以长缓存，实时数据应该走推送而不是轮询 + 缓存。
常见问题
延迟数据会影响回测结果吗？
会，但影响取决于策略周期。按日调仓的策略，延迟几分钟对结果影响极小；分钟级或更短周期的策略，延迟会直接改变信号，回测结果不可信。
免费套餐的数据可以用来做什么？
免费套餐覆盖加密、美股与金属的延迟数据，适合接口联调、原型验证、历史数据回填和低频分析。它的定位是让你在零成本下跑通完整流程。
怎么确认某个市场在我的套餐下是实时还是延迟？
两种方式：查响应里的 delayed 字段，或对照套餐的市场权限说明。建议在代码里对关键市场做断言，避免上线后才发现是延迟数据。
可以先按延迟开发，之后再切实时吗？
可以，而且推荐。延迟与实时的数据结构完全一致，切换只需改套餐权限，不需要重构代码。但要注意缓存策略需要相应调整。
Level 2 数据属于哪一类？
Level 2 提供更深的订单簿档位，属于更高权限的范畴，通常只在最高档套餐开放。它和「实时 / 延迟」是两个独立的维度——Level 1 也可以是实时的。
延迟数据更便宜是因为质量更差吗？
不是。底层是同一份数据源，区别只在于你什么时候能拿到。延迟档位更便宜，是因为数据的即时商业价值更低，而不是因为准确性更差。
下一步
先明确你的决策周期，再按市场维度核对权限。各套餐的市场覆盖与实时 / 延迟划分见 套餐定价；具体市场的权限说明可查阅 加密货币行情 与 美股行情 页面；接口返回的 delayed 与 unavailable 字段定义见 多市场行情接口文档；如果你在权衡订单簿深度，可先看 Level 1 与 Level 2 对比。