外汇实时行情API接入：WebSocket重连后，怎样避免显示旧报价？

摘要：接入外汇实时行情API后，WebSocket重连成功并不等于页面已经恢复。本文面向负责外汇看板、汇率监控或价格提醒的开发者，以 TickDB 的 EUR/USD 真实订阅为例，走完连接、订阅、主动断开与重连的过程，讲清报价时间、心跳和页面状态怎样配合，帮团队少被旧数据误导。文章里的恢复顺序和验收清单，产品经理和技术同事可以一起对照检查页面表现。

一句话答案：WebSocket 重连后，不要因为连接灯变绿就恢复页面；要重新订阅目标货币对，收到 EURUSD 新报价，并确认报价时间晚于断线前最后一条记录、落在允许范围内，再切回正常状态。

行情页上的连接灯重新变绿，EUR/USD 却还停在断线前的价格。如果价格提醒跟着恢复运行，它使用的可能仍是上一条旧记录。用户关心的是“这条报价更新到什么时候”，页面却只告诉他“网络又连上了”。

接入时，最好把连接状态和报价状态分开处理：重新订阅目标货币对，收到时间可用的新报价，再恢复正常提示。TickDB 的 WebSocket 行情订阅可以持续提供 EURUSD 报价及其报价时间；下面用一段真实运行记录，把这条恢复路径完整走一遍。

美联储官网列出的下一次 FOMC 会议安排在 2026 年 10 月 27—28 日。重要日程前的外汇监控，除了配好价格提醒，也值得提前检查：数据中断后页面会怎么恢复。美联储会议日历可以作为检查节点。

连接恢复后，还要检查目标报价及其时间。

WebSocket重连后，绿灯亮了为什么还要等报价

本节结论：连接恢复只证明通道建立，页面恢复还要等目标报价通过检查。

行情页的恢复过程，可以拆成下面几个时刻：

把这三个时刻画成时间线，就是：新连接打开 → 重新订阅 → 订阅确认或心跳 → 目标报价到达 → 时间检查通过 → 页面恢复正常。

产品需求也可以写得更具体一点：断线时保留最后价格和报价时间，显示“连接中断”；重新连上以后，先显示“等待 EURUSD 报价”；等报价通过检查，再切回正常状态。

这样，用户能看到数据停在了哪里，技术同事也有明确的恢复条件。

外汇实时行情API接入实测：从主动断开到收到新报价

本节结论：这次实测里，从新连接打开到收到通过检查的新报价，相隔 491 毫秒。

2026 年 10 月 22 日，我们使用 Node.js 26.0.0 和 ws 8.22.0，订阅了 EURUSD 行情。最终这次运行持续约 25 秒，收到 62 条通过基础检查的报价，经历两次连接和一次本客户端主动断开。脚本最长运行时间设为 90 秒。

下面是日志里的恢复顺序。时间统一使用 UTC，北京时间需要加 8 小时。

主动断开前，最后一条报价为 1.11953。恢复后第一条通过检查的新报价为 1.11952，它携带的报价时间是 13:57:42.469Z。

这次断开是测试脚本主动发起的。原始消息和事件日志都留着，可以对照查看重连后先收到了什么、页面为什么恢复正常状态。

从新连接打开到收到通过检查的新报价，相隔 491 毫秒，中间包含重新订阅和等待报价的客户端流程。

外汇实时行情API接入：先把 EUR/USD 报价接进来

本节结论：每次连接打开都要重新订阅，不能默认上一次订阅还有效。

当前文档给出的 WebSocket 地址是：

wss://api.tickdb.ai/v1/realtime

认证使用 api_key 查询参数。密钥从后端安全环境读取，日志里不要输出带密钥的完整连接地址。连接与重连实践可以对照当前文档检查。

每次连接成功打开后，示例脚本发送下面的订阅消息：

{
   
  "cmd": "subscribe",
  "data": {
   
    "channel": "ticker",
    "symbols": ["EURUSD"]
  }
}

连接重新建立后，也要再发一次。示例不会默认上一次连接的订阅还有效。

读懂第一条报价

本节结论：报价时间和客户端接收时间都要保存，二者不是同一个东西。

这是最终运行中保存的第一条 EURUSD 行情消息：

{
   
  "cmd": "ticker",
  "data": {
   
    "symbol": "EURUSD",
    "type": "forex",
    "last_price": "1.11950",
    "bid_price": "1.11950",
    "ask_price": "1.11951",
    "spread": "0.00001",
    "timestamp": 1792677449581
  }
}

这里的 timestamp 是毫秒时间戳，对应 2026-10-22T13:57:29.581Z；客户端收到这条消息的时间是 13:57:29.745Z。

这两个时间都值得保存。前者是报价自带的时间，后者是消息到达本客户端的时刻。两者之差还包含时钟偏差和链路处理，不能直接当成单程网络延迟。

价格按返回的字符串保存。需要双边报价的页面，还要分别保留买价 bid_price 和卖价 ask_price。这些外汇行情消息应当作报价更新来用，不要改写成已经发生的外汇成交记录。行情订阅的具体字段可以对照当前文档核对。

价格没变，也可能一直在更新

本节结论：判断行情是否更新，要看报价时间，不能只看价格跳不跳。

原始记录中有这样两条相邻报价：

价格相同，报价时间却向前推进了。对用户来说，屏幕上的数字没有变化；对程序来说，它已经收到了新的观察记录。

所以，监控要同时记录消息时间和报价时间。只看“这个数字多久没跳”，很难判断连接是否正常、报价还在不在更新。

WebSocket重连后，心跳为什么不能替报价过关

本节结论：心跳只证明连接有回应，目标报价仍要单独等、单独检查。

这次运行中，新连接打开以后，先收到订阅确认和应用层 pong，随后才收到 EURUSD 报价。

示例脚本会继续等待，并检查报价是否满足以下条件：

• 标的是 EURUSD；
• 价格和毫秒时间戳可用；
• 报价时间晚于主动断开前的最后一条报价；
• 落在示例设定的时间范围内。

前面提到的恢复后第一条报价，其报价时间和接收时间都通过检查，随后记录恢复。

心跳回复不会更新页面上的报价。WebSocket 协议本身的 Ping/Pong 控制帧，和接口的 JSON ping、pong 消息要分开看。日志里的这次 pong 是应用层消息；目标货币对的价格仍然从 ticker 消息里取。RFC 6455 对 Ping/Pong 控制帧有定义，心跳消息也可以对照当前文档核对。

把判断过程写成流程，就是：收到消息 → 是不是 EURUSD → 价格和时间戳是否可用 → 报价时间是否晚于断线前最后一条 → 是否落在允许时间范围 → 通过则恢复，不通过则继续等待。

没有新消息时，旧报价也会继续变老

本节结论：时间检查要持续运行，不能只在收到消息时跑。

如果程序只在收到消息时检查时间，一旦没消息了，这段检查就不会跑。最后一条报价可能一直挂着“正常”状态。

本次运行的脚本每秒重新判断当前显示状态。即使连接还开着、没有新消息，旧报价超过设定时间后也会转入相应提示。

本示例把报价过期阈值设为 5 秒；如果报价时间比本地时钟还快，也留 5 秒容忍范围，避免因时钟偏差误判。这些是示例里设的参数，实际项目要按看板、提醒规则和时钟环境调整。

页面可以继续保留最后价格，同时显示报价时间和等待提示。这样，用户既能看到最后一次记录，也能知道当前状态。

连续重试时，等待时间怎样安排

本节结论：重试要分阶段退避，连接成功后重置计数并重新订阅。

当前连接指南采用分阶段等待：

示例按这个顺序安排重试；连接成功打开后重置计数，并重新订阅。认证或权限错误要先处理具体原因，一直重试解决不了权限问题。重连指南可以对照当前文档检查。

日志还为每次连接记录独立编号，方便把断线前后的消息分开查看。

报价恢复了，断流的那一段仍要留下

本节结论：重新收到报价，不会自动补出中断期间的每一次更新。

CSV 逐条保存连接编号、接收时间、报价时间、价格和检查状态。事件日志另外记录主动断开、连接打开、发送订阅和收到新报价的时刻。

这些记录可以用来给看板或下游数据标出中断窗口。后面重新收到报价，也不会自动补出中间每一次更新。

比如，从断线前最后一条报价到恢复后第一条通过检查的报价，只能比较这两个观察点；仅凭它们，还原不了期间的每次变化、价格穿过某个阈值的准确时刻，也说不清具体漏了多少条消息。

需要历史 K 线时，要另外查询对应时间窗口，并检查返回结果。K 线汇总的是一个周期里的数据；补上 K 线以后，也要保留实时订阅曾经中断的记录。

给产品与技术同事的页面验收清单

本节结论：验收不要只看连接灯，要逐项检查页面状态。

这张表可以直接放进需求文档。先约定页面要告诉用户什么，再让技术实现对应检查，比只写一句“支持断线重连”更容易验收。

常见问题

Q1：第一次接外汇实时行情，从哪里开始？

先只订阅 EURUSD，确认收到订阅回应和真实的 ticker 消息，再扩展货币对。具体账户权限和可用标的，以当前文档和实际返回为准。

Q2：连接恢复了，却一直没有 EURUSD 报价，怎么办？

保留等待状态，依次检查发出去的订阅、确认消息、返回标的、服务端错误和报价时间。收到心跳或其他货币对的数据，都不应该解除 EURUSD 的等待提示。等待状态要一直保持到目标报价通过检查，或者明确转为异常提示。

Q3：后续需要当前快照或历史走势，怎样配合？

按页面任务分别查询行情快照或历史 K 线，给结果保留各自的时间和用途；订阅中断记录继续保留，方便解释数据来源。具体接口以当前文档和实际返回为准。

把恢复条件写进产品需求

本节结论：页面恢复条件要写成可验收的状态变化，不能只写“支持断线重连”。

外汇行情接入后，页面应该能解释清楚：订阅了什么、最后收到什么，以及为什么从等待状态恢复正常。

这次实测留下了完整顺序：连接重新打开，客户端再次订阅，随后收到报价时间推进、并通过检查的 EURUSD 报价。对照恢复顺序和时间图，团队可以把“页面什么时候恢复”写进验收条件。

用自己的货币对做一次同样的测试，再决定看板和提醒什么时候恢复。连接灯和报价时间一起看，用户才更容易判断眼前这条数据该怎么用。

数据记录于 2026 年 10 月 22 日，用于演示行情处理，不构成投资建议。

术语表

• 报价时间：行情消息自带的 timestamp，表示这条报价对应的时间。
• 客户端接收时间：本客户端收到消息的时刻，和报价时间不是同一个概念。
• 恢复检查：判断新报价是否属于目标标的、时间是否可用、是否晚于断线前最后一条、是否落在允许范围内。
• 断流窗口：从最后一次有效报价到恢复后第一条有效报价之间的时间段，中间更新不会自动补出。
• 应用层心跳：接口 JSON 消息里的 ping、pong，和 WebSocket 协议控制帧不是一回事。

参考资料

1. TickDB：WebSocket连接与重连实践、行情订阅、心跳消息
2. IETF：RFC 6455中Ping/Pong控制帧的定义
3. 美联储：FOMC会议日历