A股实时行情看板别只显示最后价格：多股票监控还要看什么状态

摘要：多股票看板最容易犯的错，是把“拿到一个价格”当作“这一格已经实时更新”。用 TickDB 接 A 股行情时，REST ticker 适合拿快照，WebSocket ticker 适合接持续消息；页面还需要自己保存每只股票最近一次消息时间和状态。

做 A 股行情看板时，最迷惑人的画面往往是：页面没有报错，每只股票也都有一个价格。

于是你会自然地觉得，看板已经正常跑起来了。

但这两个判断不是一回事。一次价格返回，只能说明那一刻请求拿到了结果；它不能替你说明这只股票刚刚收到过持续行情消息，更不能说明同一张看板里的其他股票也在更新。

我建议把这个问题拆开处理。TickDB 的 REST ticker 用来拿一批股票的当前快照，WebSocket ticker 用来接持续消息；至于“这一格现在能不能解释为最新状态”，要由你的看板自己维护。

下面用一个很小的实测和状态表说明这件事。

先说结论：价格字段之外，还要有状态字段

一张多股票看板，至少别只存 last_price。我会给每个标的加上这几个字段：

这样做不是为了把页面做复杂，而是为了避免最危险的一种错觉：两个格子都显示价格，于是你以为它们都在实时更新。

TickDB 在这里做什么

这篇只用到两项能力。

• GET /v1/market/ticker：按需查询一个或多个标的的行情快照。
• WebSocket ticker 频道：订阅持续行情消息。

它们的分工很简单：REST 适合启动时取一批快照，或者在你自己的恢复流程里补查；WebSocket 负责让看板收到后续消息。

重连、重新订阅、补查、去重，以及页面该显示“正常”还是“待确认”，都还是应用自己的工作。别把这些默认算成数据接口自动替你完成的事。

这次真实调用，给了一个很直观的反例

本次用 600519.SH 和 000001.SZ 做有限时长调用。两个标的只是接口样本，不是投资建议。

REST ticker 返回成功，两个标的都拿到了 last_price。随后连接 WebSocket、订阅 ticker，连接与订阅均成功；在这次观察窗口里，000001.SZ 收到了一条 ticker 消息，而 600519.SH 没有收到。

如果你的页面只画价格，两格看起来没有区别：都有数字。

但状态表应该诚实地显示差异：

这张表没有评判哪只股票，也没有说明服务稳定性。它只忠实地记录了这一次运行中，每个格子到底看见了什么。

最小实现：把快照和消息分开写入状态

下面是精简后的思路。生产环境还要补上你自己的超时、重连和存储策略；这段代码只展示状态如何落表。

const state = new Map();

function ensure(symbol) {
  if (!state.has(symbol)) {
    state.set(symbol, {
      symbol,
      last_price: null,
      last_message_at: null,
      state: "unknown",
      recovery_check: "not_triggered"
    });
  }
  return state.get(symbol);
}

// 1) REST 快照：启动时或恢复后补查
for (const row of restResponse.data) {
  const item = ensure(row.symbol);
  item.last_price = row.last_price;
  if (item.state === "unknown") {
    item.state = "snapshot_only";
    item.recovery_check = "REST_snapshot_present_but_WS_not_confirmed";
  }
}

// 2) WebSocket ticker：逐标的更新时间和状态
ws.onmessage = ({ data }) => {
  const msg = JSON.parse(data);
  if (msg.cmd !== "ticker") return;

  const item = ensure(msg.data.symbol);
  item.last_price = msg.data.last_price;
  item.last_message_at = new Date().toISOString();
  item.state = "live_message_seen";
  item.recovery_check = "not_triggered_in_limited_run";
};

页面上不需要立刻做成一套复杂的风控系统。先让每个格子能说清楚自己是“刚收到消息”，还是“只保留了一次快照”。这一步做到了，后面再加超时阈值、断线重订阅和 REST 补查，才有地方落。

实测里用的订阅格式

{
  "cmd": "subscribe",
  "data": {
    "channel": "ticker",
    "symbols": ["600519.SH", "000001.SZ"]
  }
}

这次运行的可观察结果是：REST 返回成功；WebSocket 连接、订阅成功，并收到一条 000001.SZ 的 ticker 消息。它不证明延迟、全市场覆盖、持续连接表现或自动恢复能力。真正要做生产看板，仍要用自己的交易时段、订阅列表和异常条件继续观察。

最后留一个很实用的检查动作

下次你打开多股票看板时，不妨先问一句：

这张表里每个价格，最近一次是怎么来的？

如果页面答不出来，就别急着把它叫“实时看板”。

FAQ

怎么开始？

先选两三只你自己要监控的 A 股，调用一次 REST ticker 拿快照，再订阅 WebSocket ticker；把上面的五列状态直接打印到控制台或页面上。

数据异常怎么定位或补回？

先看 last_message_at 和 state。发现某一格长期只有 snapshot_only，不要拿旧价格继续当作持续更新；按你的应用流程重新订阅，并用 REST 再补一次快照。

TickDB 还能解决什么下一步问题？

当你把单标的消息状态管清楚后，可以再把同一套处理扩展到更多监控对象。前提仍然一样：先把每个对象的当前状态展示出来，再谈更大的看板。

风险提示：文中样本仅用于演示行情接口与看板状态处理，不构成任何投资建议或交易依据。本文为一次有限时长技术运行记录，不对性能、稳定性、延迟、覆盖范围或自动恢复作出承诺。

如果你正在做自己的 A 股行情看板，可以先用两三个真实监控标的跑出这张状态表；确认每个格子能说明“价格从哪里来、最后何时更新”，再继续扩展功能。

通过 TickDB API 获取实时行情数据

一个 API 接入外汇、加密货币、美股、港股、A股、贵金属和全球指数的实时行情。支持 WebSocket 低延迟推送，免费开始使用。