行情数据是否最新?A股、港股、美股价格不动,先别急着下结论

TickDB Research ·

行情数据是否最新?A股、港股、美股价格不动,先别急着下结论

最危险的行情,不是页面没有价格。

而是价格看起来一切正常,你却在拿上一交易时段的数字解释今天的涨跌。

当它继续被写进跨市场比较、监控告警,甚至交给 AI 分析,错误就不再只是数据问题,而会进入你的判断。

先别急着解释涨跌。先确认这条价格,是否属于本轮市场状态。

TickDB 是面向量化研究、行情监控和投资工具的实时行情API。本文用它的 ticker 时间戳、交易日和当地交易时段,做一件很具体的事:判断一条 A股、港股或美股价格,现在能不能进入本轮比较。

有价格,不等于能直接比较

跨市场复盘时,最容易犯的错是只看“最后价格有没有变化”。

但一条价格至少有四个问题要先回答:

它属于哪个市场?
它是哪一个字段?
它对应什么时间?
那个市场当时是否仍在目标交易时段?

少一个答案,价格就可能被误读。

比如,A股和港股已经收市,美股却仍在常规交易时段。三条价格都在屏幕上,但它们并不属于同一种“当前市场状态”。

我用 TickDB 跑了一次三市场检查

本次观察时间:2026-07-30 14:26 UTC。

研究规则预先设为:

目标时段:各市场常规交易时段
新鲜度阈值:300 秒
标的价格价格时间观察时的当地市场时间资格状态下一动作
贵州茅台 600519.SH1361.7607:00 UTC22:26,中国时间休市保留最后有效价格;等待目标时段,或明确按收盘价比较
腾讯控股 700.HK471.8008:08:22 UTC22:26,香港时间休市保留最后有效价格;等待目标时段,或明确按收盘价比较
苹果 AAPL.US331.7014:26:42 UTC10:26,纽约时间当前可解释可以进入本轮比较,并保留字段与时间

这次结果最重要的地方,不是三只股票分别涨跌多少。

而是:

A股和港股的交易日仍然成立,但观察时刻已经不在常规交易时段;美股仍在盘中,且价格时间戳处于本次 300 秒阈值内。

所以,前两条价格不该被误读成“数据不更新”,第三条价格也不该和前两条一起被当成同一种实时状态。

休市不是陈旧。价格没动,也不等于数据故障。

美股更容易把字段混在一起

同一次 AAPL.US 返回里,几个价格字段的时间并不相同:

字段价格对应时间
常规 last_price331.702026-07-30 14:26:42 UTC
盘前报价333.122026-07-30 13:30:01 UTC
盘后报价340.002026-07-29 23:59:54 UTC
夜盘报价338.492026-07-30 08:00:00 UTC

如果只写“苹果最新价”,这几个字段就可能被混成一个概念。

但它们对应的交易阶段、时间和解释方式不同。

价格本身不是结论;价格字段加上时间状态,才是研究输入。

一张五状态资格卡

我把价格先分成五类,再决定下一步:

资格状态先做什么
当前可解释可以进入本轮比较,保留市场、字段和时间
休市或非目标时段不把最后价格当成当前变化;等待开市或明确按收盘价比较
可能陈旧重新请求,并检查数据链路
信息不足补齐市场、字段、时间戳和交易时段再判断
需要复核继续查最近成交、K线、盘口或第二来源

这张卡不是 TickDB 自动返回的结论。

TickDB 提供价格、时间戳、交易日和交易时段这些事实输入;资格判断由你的研究规则完成。

真实运行的核心调用

下面是本次完整脚本中的核心请求:

ticker_record = call(
    api_key,
    "REQ-TICKER-ALL",
    "/v1/market/ticker",
    {
        "symbols": "600519.SH,700.HK,AAPL.US",
        "type": "stock",
    },
)

trade_day_us = call(
    api_key,
    "REQ-TRADE-DAYS-US",
    "/v1/market/trade-days",
    {
        "market": "US",
        "beg_day": "20260730",
        "end_day": "20260730",
    },
)

sessions_us = call(
    api_key,
    "REQ-SESSIONS-US",
    "/v1/market/trading-sessions",
    {"market": "US"},
)

然后把 ticker 的时间戳换算为当地市场时间,结合交易日和目标时段,输出:

symbol
price_field
quote_timestamp_utc
local_market_time
qualification_state
reason
next_action

这比只打印一个 last_price 多了一层很重要的判断:这条价格能不能解释。

已有数据源,也值得跑一次

不需要先迁移系统。

拿你自己常看的三只标的:一只 A 股、一只港股、一只美股;在同一观察时刻查价格、时间戳、交易日和交易时段。

然后问自己:

我现在看到的三条价格,是不是都属于同一种市场状态?

如果答案不确定,问题不在于你有没有行情,而在于你的研究流程还没有把“时间资格”写成可检查规则。

TickDB 在本文里的价值,就是把价格和它的市场时间上下文放进同一条检查链,让你先确认输入,再解释变化。

FAQ

1. 怎样区分“休市”和“可能陈旧”?

先看观察时刻是否在该市场的目标交易时段内。已经收市时,最后价格可以保留,但不能被当成当前盘中变化;市场本应交易、时间戳却超过你预设阈值时,才进入“可能陈旧”。

2. 为什么不统一规定“超过几分钟就是旧数据”?

不同任务要求不同。盘中监控、收盘复盘、跨市场日报,对新鲜度的要求并不一样。阈值要由具体研究任务提前写清,而不是事后凭感觉判断。

3. 出现“需要复核”后,TickDB 还能做什么?

这篇先用 ticker、交易日和交易时段完成第一层资格判断。需要复核时,再按问题补查最近成交、历史 K 线或盘口等证据;先确定该查什么,再扩大数据范围。

真正可靠的市场判断,不是先问价格涨跌意味着什么,而是先确认:这条价格有没有资格进入判断。

相关文章

量化回测结果隔几个月就变了?代码没动,先查数据版本

量化回测结果隔几个月就变了?代码没动,先查数据版本 > 半年前跑出来的回测曲线很好看。今天把代码翻出来,参数没改,逻辑没改,区间也没改,但结果就是对不上。真正变化的,可能不是策略,而是输入数据:复权口径、样本池版本、停牌处理、行情抓取时间和原始响应,任何一项没留版本,旧回测都可能复现不了。 半年前跑出来的回测曲线很好看。今天把代码翻出来,参数没改,逻辑没改,区间也没改,但结果就是对不上。 第一反应

TickDB Research ·

从盯盘、AI分析到团队复盘,行情数字进入判断之前,至少要说清这4点

标题:从盯盘、AI分析到团队复盘,行情数字进入判断之前,至少要说清这4点 摘要:如果你经常盯A股、美股、港股或加密行情,又想把价格拿去做复盘、AI分析或研究记录,你需要的不只是“看到数字”。如果你已经接入了实时行情API,当团队里三个人引用了“同一个价格”但三份结果对不上时,你能不能追溯到每个人当时取到的具体快照?TickDB不替你判断涨跌,但能让你取到的行情数字更容易被记录、核对和复查。 !im

TickDB Research ·

行情数据源冲突时,你应该相信谁?看完这篇就答案

你接了两个行情数据源,同一个symbol、同一时间附近,一个返回100.12,另一个返回100.18。接口都返回成功,价格都像真的。此时最危险的反应不是怀疑其中一个错了,而是立刻选一个你更熟的数据源相信。这篇文章提供一套多源冲突时的证据链仲裁方法——不判断谁更准,只追查每条价格背后的symbol、时间戳、市场状态、字段口径和原始返回,让数据自己说话。

TickDB Research ·

外汇行情还在更新吗?用 Python 订阅 EURUSD 并记录双时间

适合正在开发外汇报价监控、需要确认脚本持续收到行情的 Python 开发者。使用 TickDB 的 WebSocket 行情订阅,记录 EURUSD 报价、数据时间和本机接收时间,生成原始消息与 CSV。通过目标报价数量、接收间隔和数据时间推进情况,区分连接仍在、消息到达与数据更新。本次30秒订阅观察收到38条目标报价;代码支持有限运行和自动保存结果,方便在自己的环境复查。

TickDB Research ·

Codex股票分析实测:用TickDB MCP查A股行情、财报数据和估值

用Codex分析A股,怎样把行情、财报数据和估值放在一起看?本文以寒武纪为例,实测通过TickDB MCP获取历史行情、单季财务与PE估值,结合公司公告核对期间和口径,再用Python生成事实卡、整理个股研究笔记。附可复制的任务指令、真实输入和可运行代码,适合个人研究者与AI投研产品团队,减少重复查数和整理。

TickDB Research ·