免费A股数据接通了？这4项不验证，回测可能白跑
TickDB Research ·
你第一次把A股数据接进研究脚本，终端很快打印出价格。你看了一眼，觉得没问题，继续写因子。
直到回测跑到第三个小时，你开始怀疑数据不对。你回头检查，发现自己从来没验证过返回行里的代码，是否真的对应你请求的那两只股票。如果应用层没有把返回行与请求代码对齐，可能发生错配——你拿到的可能不是你要的那只票的数据。
有价格，只能说明这一次快照请求成功。它还没有回答这份数据是否满足你的研究任务。免费是成本条件，不是"历史、实时、稳定、字段都合适"的证明。
本文用TickDB的REST ticker做一次最小快照核对：一次请求多个代码，先看HTTP状态、API返回状态、返回代码是否对应、时间戳是否可解释。TickDB在这里的角色是提供快照输入，它不自动完成回测资格判断、持续更新或异常恢复。
30秒抓住重点
问题：免费接口返回价格≠数据可用于研究 根因：没有验证请求是否成功、返回是否对应、时间是否可解释 方案：4项最小验证——HTTP状态、API状态、代码对应、时间戳 效果：避免拿错数据跑完整个回测 适合：第一次接免费A股数据接口、准备写策略的人
先问清楚：你要这份数据干什么
| 你的任务 | 先确认什么 | 一次价格返回够不够 |
|---|---|---|
| 临时观察 | 请求是否成功、代码是否对应、时间是否可解释 | 只能作为起点 |
| 历史研究或回测 | 历史范围、复权口径、缺失处理 | 不够 |
| 持续监控 | 更新方式、异常处理、任务恢复 | 不够 |
先把任务写清，后面的验证才不会跑偏。
最小验证：4项必须打印
先不要急着把返回值塞进因子、策略或看板。跑这段：
const symbols = ["600000.SH", "000001.SZ"];
const url = new URL("https://api.tickdb.ai/v1/market/ticker");
url.searchParams.set("symbols", symbols.join(","));
url.searchParams.set("type", "stock");
const response = await fetch(url, {
headers: { "X-API-Key": process.env.TICKDB_API_KEY },
signal: AbortSignal.timeout(15000)
});
const body = await response.json();
const rows = Array.isArray(body.data) ? body.data : [];
console.log({
httpStatus: response.status,
apiCode: body.code,
returned: symbols.map(symbol => ({
symbol,
found: rows.some(row => row.symbol === symbol)
}))
});
这段代码实际打印了三项，第四项需要你补上。
第一，HTTP状态。 httpStatus 告诉你这次HTTP请求是否收到成功响应。200 说明这次请求被成功处理；其他值说明请求层出了问题，后面的数据先别用。
第二，API状态。 apiCode 告诉你接口是否成功处理。HTTP 200不代表业务成功，API层的状态码是数据是否有效返回的第一道关。但code=0只说明接口处理成功，数据是否适合你的研究，还要看代码对应和时间。
第三，代码对应。 你请求了600000.SH和000001.SZ，返回行里是否真的包含这两个代码？如果found是false，说明请求代码没有得到对应返回行，不能把这次请求视为满足。
第四，时间戳。 返回行里的timestamp，是否在你预期的时间范围内？这一项当前代码没有打印，你需要自己补上。时间戳不能简单用"几小时前就是旧数据"来判断，还要结合交易时段和市场状态。比如非交易时段取到的快照，时间戳是收盘时刻，这是正常的。
这4项里任何一项不通过，先不要把这次结果当成目标任务的有效输入。
真实运行结果：这次验证说明了什么
2026年9月2日，我用两个A股代码做了一次查询。
这次真实运行的可观察结果是：
httpStatus: 200
apiCode: 0
returned:
- symbol: "600000.SH", found: true
- symbol: "000001.SZ", found: true
这个结果只说明：两个代码、一次请求、该时刻、该权限下的快照查询成功。 它不说明历史数据可用，不说明持续更新正常，更不说明你的回测会有任何结果。
价格只是返回字段之一。更值得先确认的是：你请求的对象有没有真的回来。
一句话本质判断
拿到快照之后，你只需要问自己一句：我拿到的是不是一个能回答我研究问题的数据点？
如果你做的不是临时观察，那这张快照只是起点，不是终点。做回测就继续核对历史区间和复权口径。做监控就继续设计更新、异常和恢复逻辑。一次REST请求不是持续状态，一张快照不能替代历史验证。
FAQ
我如果只想随便看看行情，是不是不用做这些检查？
对。临时看一眼行情，不用跑这4项。但如果你接下来要写进回测、写进监控脚本，那你的代码会自己跑到有问题的数据上去。你现在省掉的检查，回测跑到最后会加倍还给你。
结果异常时怎么定位？
保留请求参数、时间、HTTP状态、API返回状态和原始响应。不要只截图一个价格。以后重跑或换数据时，才能知道问题出在请求、返回还是后续处理。
如果我验证这4项全过了，是不是就可以写策略了？
够你开始写，但不够你写完。这4项验证的是"数据有没有正常回来"，不是"数据能不能支撑你的研究"。历史深度、复权处理、缺失值行为，每一项都需要单独确认。
你的研究脚本里，跑了一圈的因子，是真是假？ 翻回第一行代码，看它有没有打印过HTTP状态、返回代码和时间戳，就知道了。