摘要：很多团队做行情产品时，把“查价格”“拉K线”“做实时看板”“让AI回答行情问题”拆给了不同来源。开始看似省事，后来却要反复处理代码格式、字段名称、时间口径和数据留痕。更稳妥的起点，是先选一层能被自己验证的数据入口。本文用一次当天重新运行的 TickDB 实测，检查 REST ticker、REST K 线和 WebSocket 订阅三条基础链路，说明一套 A 股行情数据层能解决什么，又不能替你解决什么。
这篇文章解决什么问题
一个行情面板、一段研究脚本和一个会回答问题的 AI 工具，表面上是三件事。但它们的第一层需求其实相同：都需要一份说得清来源、字段和时间的行情数据。
很多人是在系统长大以后才发现问题。面板从一个接口取最新价，研究脚本从另一个来源拉 K 线，AI 又根据第三套信息回答问题。每个局部看起来都能用，可一旦数字不一致，就没人能快速解释：是哪一个 symbol、哪一个字段、哪一个时间窗口出了问题？
产品选型的第一问，不是“它有多少功能”，而是“我能不能把它放进自己的数据链路，并且每一步都能复核”。
本文的核心方法论
这篇文章只做一件事：用 TickDB 对 A 股样本跑通 REST ticker、REST K 线和 WebSocket 订阅三条基础链路，说明一套统一行情数据层能解决什么，不能解决什么。全文的逻辑结构是——
是什么：一套 A 股行情数据层，至少要能回答三类问题——查快照时能不能确认 symbol 和字段身份，拉 K 线时能不能确认周期和 OHLCV 契约，做实时面板时能不能确认连接和订阅链路。这三类问题不解决，面板、脚本和 AI 工具就是各说各话。
为什么：很多人把数据源当成“能出数字就行”的工具，但不同数据源的 symbol 格式、字段名称、时间戳语义各不相同。等系统长大、数据源增多、团队成员变多后，每一次数字不一致都要花时间排查——不是策略错了，不是模型错了，是三个数据源对“同一个价格”的定义不一样。
怎么样：先对三个 A 股样本发 ticker 请求，验 symbol 一致性和字段可解析性；再用 600519.SH 拉 K 线，验周期、OHLCV 字段和字段之间的逻辑关系；最后用 WebSocket 订阅 ticker，验连接和订阅确认链路是否走通。每一步都配真实终端截图、字段核对表和最小校验代码。最后给一张三条链路的检查清单，你可以直接拿去验自己的候选数据源。
这套方法不绑定 TickDB——你用任何行情 API，都可以用同样的逻辑跑一遍 ticker、K 线和 WebSocket，确认三条基础链路是否能被程序化验证。
读完你能拿走什么
- 一套 A 股行情数据层的最小验收框架：ticker 验身份，K 线验周期和 OHLCV 契约，WebSocket 验连接和订阅链路。
- 三份可直接运行的校验代码片段，覆盖 REST ticker、REST K 线和 WebSocket 订阅的核心校验逻辑。
- 一张三条链路的检查清单，每次切换数据源、接入新品种或排查数据不一致时直接对照。
- 一套“能证明什么、不能证明什么”的边界声明，帮你区分接入验证、交易信号和生产稳定性。
一套行情数据层，先服务三种任务
对大多数 A 股应用来说，先把下面三类任务分清，比一上来堆功能更重要：
| 你的任务 | 先需要什么 | 本文的验证方式 |
|---|---|---|
| 查询某只股票当前快照 | ticker 与字段身份 | REST ticker |
| 准备历史图表或研究样本 | K 线周期与 OHLCV 字段 | REST kline |
| 做持续更新的面板或监控 | 连接与订阅链路 | WebSocket ticker |
它们不是三种互相替代的产品，而是同一条数据链路上的不同环节。
TickDB 在这里的位置，是作为面向开发者、AI Agent、量化研究者和金融应用团队的行情数据 API。它支持 REST、WebSocket、MCP、Skill、CLI 等接入方式；本文只验证其中 REST 与 WebSocket 的三条 A 股基础路径。AI 工具调用（MCP）需要单独跑证据，不能从这次 REST 成功直接推出。
第一件事：用 ticker 确认“你问的是谁，拿到的是谁”
这次重新请求了 600519.SH、000001.SZ 和 300750.SZ。请求使用 REST GET /v1/market/ticker，通过 X-API-Key 鉴权，并明确传入 type=stock。
本轮运行中，HTTP 返回 200、业务 code=0，三个请求 symbol 都出现在返回数组里。脚本没有只看“有价格”，还逐项检查了：返回的 symbol 是否和请求一致；type 是否为 stock；last_price 等数值字段能否被程序解析；timestamp 是否是 13 位毫秒整数；返回是不是数组，而不是被客户端错误地当成一个对象。
这一步的产品价值不在于“展示三只股票的价格”，而在于让你的面板、脚本或后续 AI 流程先有一份可核对的结构化输入。
下面是本次 runner 中实际使用的最小 ticker 校验逻辑：
resp = requests.get(
"//api.tickdb.ai/v1/market/ticker",
headers={"X-API-Key": os.environ["TICKDB_API_KEY"]},
params={
"symbols": "600519.SH,000001.SZ,300750.SZ",
"type": "stock",
},
timeout=20,
)
payload = resp.json()
rows = payload.get("data")
assert resp.status_code == 200
assert payload.get("code") == 0
assert isinstance(rows, list)
assert {row["symbol"] for row in rows} == {
"600519.SH", "000001.SZ", "300750.SZ"
}
第二件事：K 线不是“历史价格列表”，而是一份周期契约
当你从最新价走向图表、研究或回测，真正要检查的不只是“有没有 10 年数据”之类的宣传句，而是请求的周期、返回的字段和字段之间的关系。
本轮用 600519.SH 请求 interval=1d、limit=3 的 K 线。结果返回 3 条样本，symbol 和 interval 与请求相符，单根 K 线包含 time/open/high/low/close/volume/quote_volume。
这里最值得保留的不是某个具体价格，而是校验习惯：high 不应低于开盘、最低和收盘等价格；low 不应高于这些价格；time 的精度需要明示，但不能被误解为延迟承诺；close 是周期字段，不能和某次 ticker 的 last_price 混成同一件事。
如果你把数据层建立在这样的可检查约束上，后面换成图表、导出 CSV 或交给分析工具时，至少知道自己传递的是哪一类数据。
第三件事：WebSocket 连上了，不等于实时面板已经完成
做行情面板时，最诱人的一句话是“我已经连上 WebSocket 了”。但连接成功只是起点。
本轮 WebSocket 使用 wss://api.tickdb.ai/v1/realtime?api_key=YOUR_API_KEY，订阅 ticker 的实际 JSON 为 {"cmd": "subscribe", "data": {"channel": "ticker", "symbols": ["600519.SH"]}}。
这次运行收到 connected 和 subscribe 成功确认。因此，能确认的是连接和订阅结构走通；不能确认的是交易时段的持续推送、推送频率、端到端延迟或生产稳定性。
这个边界很重要。真正的面板还要由应用自己补上断线处理、本地接收时间、状态标识和异常记录。TickDB 提供数据入口，不会替你的应用自动完成这些业务侧工作。
TickDB 适合放在什么位置
如果你只是偶尔看一眼价格，成熟行情软件已经足够。TickDB 更适合这些需要把数据“拿出来用”的场景：把 A 股数据接进自己的研究脚本、图表或监控服务；需要 REST 快照、历史 K 线和 WebSocket 订阅分别承担不同工作；希望在 A 股之外继续接入港股、美股、外汇、贵金属、指数或加密货币，而不是为每种资产重新设计一套数据入口；想让 AI Agent 处理真实行情数据，但愿意先把工具调用、原始返回和结论之间的链路留痕。
它不替你给出投资结论，也不承诺策略有效。它解决的是更前置的工程问题：让行情数据能被程序查询、被字段校验、被不同应用复用，并在出现差异时有迹可查。
选择前，先用自己的 symbol 跑这张清单
不要因为本文调用成功，就直接替自己的场景下结论。用你的 API Key、你的关注标的和目标时间段，至少走完下面三项：
| 检查 | 你要确认什么 |
|---|---|
| ticker | 请求和返回的 symbol 是否一致，字段是否能被解析 |
| kline | 周期、OHLCV 与时间字段是否符合你的图表或研究需求 |
| WebSocket | 是否收到了连接、订阅确认；盘中另测连续更新与异常恢复 |
一次运行成功只能建立一个验证基线，不能证明所有品种、所有时段和所有场景都一样。可复核，才是后续接入、扩展和排错的起点。
FAQ
Q1：TickDB 是行情软件还是数据 API？
它更适合作为数据 API 使用：开发者或金融应用把结构化行情接到自己的脚本、面板、监控和 AI 工具流程中。
Q2：REST、WebSocket、MCP 要同时用吗？
不必。REST 适合主动查询快照和历史数据；WebSocket 适合持续更新；MCP 面向支持工具调用的 AI 环境。应按场景选，并各自验证，不能混用鉴权和证据。
Q3：这次验证能证明实时性或稳定性吗？
不能。本次只证明了 A 股样本的 REST ticker、REST K 线，以及 WebSocket 的连接和订阅确认。延迟、交易时段连续推送与稳定性需要另做连续采样。
Q4：想先看官方资料，从哪里开始？
可先看 TickDB 官方 GitHub：https://github.com/TickDB/tickdb-unified-realtime-marketdata-api
最后
当一个数据源能先帮你把“请求了谁、返回了谁、什么时候拿到、字段代表什么”说清楚，面板、研究脚本和 AI 工具才有条件站在同一份事实之上。
这比看到一个漂亮的最新价更重要。
本文仅展示一次 A 股行情数据接入验证，不构成投资建议。具体字段、端点和可用范围以官方文档及你的当日实测为准。