TickDB 能做什么、不能做什么：一份诚实的产品能力图谱
"选数据供应商的第一步，不是问它支持多少个市场，而是问它不支持哪些。"——这句话是 TickDB 内容团队在撰写对比文章时最常忘记、也最重要的起点。
数据供应商的能力文档永远在告诉你"我们能做什么"，却很少主动标注"我们做不了什么"。这种信息不对称导致量化开发者在接入后才发现踩了坑：回测框架搭好了，代码跑通了，等到回测区间拉美股 tick 数据时才被告知"该品种不支持 tick 接口"。本文做一件少数供应商不会做的事——把 TickDB 的能力边界翻出来，一五一十说清楚。
一、为什么需要一张"诚实的能力图谱"
在 TickDB 的技术社群中，出现频率最高的支持工单有两类：
- "为什么我调
/trades接口返回空数据？" - "你们的美股 depth 怎么只有 1 档？"
这两类问题的根源不是技术故障，而是用户对产品边界的误判。一个在数字货币市场玩高频策略的开发者，自然会假设"trades 接口在美股同样可用"，因为这个假设在大多数数据平台上成立。问题是，TickDB 的设计哲学不是"全市场全类型覆盖"，而是"在覆盖的市场和类型上做到极致"。理解这一点，是正确使用 TickDB 的前提。
本文的目标不是给 TickDB 做广告，而是给技术决策者一张完整的地图：哪里是坦途，哪里是断头路，哪里需要绕行。做出正确的预期管理，比堆砌功能清单更有价值。
二、市场覆盖矩阵
2.1 按资产类别划分
TickDB 目前覆盖六大资产类别，但覆盖深度差异显著：
| 资产类别 | 市场数量 | 典型标的 | 覆盖深度 |
|---|---|---|---|
| 美股 | 全市场主流标的 | AAPL、NVDA、TSLA | K线 10 年级；depth 1 档；trades 不支持 |
| 港股 | 全市场主流标的 | 00700、09988 | K线 5 年级；depth 10 档；trades 支持 |
| A股 | 沪深主板、北交所 | 600000、000001 | K线 5 年级；depth 1 档；trades 不支持 |
| 数字货币 | BTC、ETH 主流币对 | BTC.USDT、ETH.USDT | K线全历史；depth 10 档；trades 支持 |
| 外汇 | 主要货币对 | EUR/USD | K线 5 年级；depth 不支持；trades 不支持 |
| 贵金属/指数 | 黄金、标普等 | XAU/USD、SPX | K线 5 年级；depth 不支持；trades 不支持 |
关键结论：如果你需要美股或 A 股的逐笔成交数据（tick 数据），TickDB 不是正确答案。这不是功能缺失，而是产品设计的主动选择——后文会展开原因。
2.2 数据类型与市场的交叉矩阵
市场覆盖的真正价值不在于"有多少个标的"，而在于"每个标的能拿到什么数据"。下面这张矩阵是 TickDB 最重要的能力文档：
| 数据类型 | 美股 | 港股 | A股 | 数字货币 | 外汇 | 贵金属/指数 |
|---|---|---|---|---|---|---|
| 历史 K 线 | ✅ 10年 | ✅ 5年 | ✅ 5年 | ✅ 全历史 | ✅ 5年 | ✅ 5年 |
| 实时 K 线 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| depth 订单簿 | ✅ 1档 | ✅ 10档 | ✅ 1档 | ✅ 10档 | ❌ | ❌ |
| trades 逐笔成交 | ❌ | ✅ | ❌ | ✅ | ❌ | ❌ |
| WebSocket 实时推送 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
灰色地带说明：
- 美股 depth 1 档：这是当前最常被问到的限制。TickDB 的美股 depth 只提供买一卖一两个价格，不含 2-10 档的订单簿深度。对于依赖多档订单簿重构的策略（如冰山订单检测、订单流不平衡因子），这构成实质性限制。
- 数字货币的 trades：支持逐笔成交，但需注意交易所的成交记录保真度。某些小币种存在刷量成交，实际策略回测时需自行过滤。
- 外汇和贵金属的 depth/trades：完全不支持。对于外汇做市商策略或黄金剥头皮策略，这不是"部分支持"的问题，而是"不可用"。
三、接口能力详拆
3.1 REST 接口矩阵
TickDB 的 REST 接口按功能分为五大模块：
| 接口模块 | 端点 | 美股 | 港股 | 数字货币 | 说明 |
|---|---|---|---|---|---|
| 实时行情 | /v1/market/ticker |
✅ | ✅ | ✅ | 最新价、24h 成交量等 |
| 历史 K 线 | /v1/market/kline |
✅ | ✅ | ✅ | 支持多周期，10年/5年/全历史 |
| 最新 K 线 | /v1/market/kline/latest |
✅ | ✅ | ✅ | 当前未完成周期的快照 |
| 订单簿深度 | /v1/market/depth |
✅ 1档 | ✅ 10档 | ✅ 10档 | ⚠️ 注意美股限制 |
| 可交易品种 | /v1/symbols/available |
✅ | ✅ | ✅ | 查询支持品种的权威接口 |
| 逐笔成交 | /v1/market/trades |
❌ | ✅ | ✅ | ⚠️ 美股/A股不可用 |
一个常见的调用错误：
# 错误做法：用 /kline 接口查询实时数据（效率低且语义错误）
import os
import requests
headers = {"X-API-Key": os.environ.get("TICKDB_API_KEY")}
# 每次轮询重新拉取历史数据，浪费配额且数据非实时
response = requests.get(
"https://api.tickdb.ai/v1/market/kline",
headers=headers,
params={"symbol": "AAPL.US", "interval": "1m", "limit": 1},
timeout=(3.05, 10)
)
# 正确做法：用 /kline/latest 获取当前 K 线快照
response = requests.get(
"https://api.tickdb.ai/v1/market/kline/latest",
headers=headers,
params={"symbol": "AAPL.US", "interval": "1m"},
timeout=(3.05, 10)
)
这个错误在 TickDB 的支持工单中排名第三，本质上是开发者混淆了两个接口的语义——/kline 是历史数据接口，/kline/latest 才是实时快照接口。
3.2 WebSocket 接口能力
WebSocket 是 TickDB 的实时能力核心，但不同数据类型的推送模式有显著差异：
| 频道 | 推送内容 | 美股 | 港股 | 数字货币 | 推送频率 |
|---|---|---|---|---|---|
ticker |
最新价、成交量 | ✅ | ✅ | ✅ | 实时触发 |
kline |
K 线更新 | ✅ | ✅ | ✅ | tick 驱动 |
depth |
订单簿快照 | ✅ 1档 | ✅ 10档 | ✅ 10档 | 实时触发 |
trades |
逐笔成交 | ❌ | ✅ | ✅ | 实时触发 |
WebSocket 鉴权方式（容易踩坑）：
# ⚠️ 正确：API Key 通过 URL 参数传递
ws_url = "wss://api.tickdb.ai/v1/ws?api_key=" + os.environ.get("TICKDB_API_KEY")
# ❌ 错误：试图用 Header 传递 API Key（WebSocket 协议不支持）
# ws = websocket.create_connection(url, header={"X-API-Key": API_KEY})
# 这个写法会收到 1001/1002 鉴权错误
四、TickDB 主动选择"不做"的三件事
这是本文的核心洞察。TickDB 的能力边界不是技术债，而是主动的产品设计选择。理解这些选择的逻辑，能帮助你判断 TickDB 是否适合你的场景。
4.1 不做美股/A股逐笔成交数据
这是最大的能力缺口，也是最需要解释的决策。
原因：美股和 A 股的交易所对 tick 数据的分发有严格的授权体系。Binance、OKX 等加密货币交易所本身开源大量原始数据，而纽交所和纳斯达克的数据需要付费授权且价格极高。TickDB 选择将资源集中在"已授权的高质量数据"上，而不是"拿到但质量参差不齐的 tick 数据"。
对策略的影响：
| 策略类型 | 是否受影响 | 说明 |
|---|---|---|
| 日线级趋势跟踪 | 不受影响 | 仅依赖 K 线 |
| 事件驱动策略（财报、宏观） | 不受影响 | 依赖 K 线 + depth |
| 订单流分析 / VPIN 策略 | 实质性影响 | 必须有逐笔成交 |
| 做市商策略 | 实质性影响 | 依赖完整 order book 重建 |
| 高频统计套利 | 实质性影响 | tick 级别价差检测 |
4.2 不做外汇和贵金属的深度数据
外汇市场的 depth 数据质量问题是 TickDB 选择不做的主要原因。外汇是 OTC 市场，没有统一的订单簿，不同流动性提供商（Liquidity Provider）给出的报价深度差异极大。即便强行聚合，也只是"看起来有数据"的伪深度。
替代方案：如果你需要外汇深度数据，可以考虑 LMAX Exchange（专业级）或者通过券商的FIX协议接入。
4.3 不做实时盘口重建（Level 2 聚合）
部分竞品提供"实时聚合多个做市商报价"的 Level 2 数据服务。TickDB 的 depth 频道是单一数据源的快照，不做跨源聚合。这意味着：
- 港股和数字货币的 10 档 depth 是单一交易所的数据
- 美股 1 档 depth 是主要交易所（纽交所或纳斯达克）的最优报价
- 不会有"全市场最优报价"聚合视图
这个限制对于日内交易和套利策略是实质性的，但对于基于价格方向判断的策略影响有限。
五、与主流竞品的真实对比
以下对比基于公开文档和开发者社区反馈，数据截至 2026 年 4 月。表格中的"✅"表示完整支持，"⚠️"表示部分支持或有条件限制，"❌"表示不支持：
| 能力维度 | TickDB | Polygon.io | Alpaca | Tushare（A股） |
|---|---|---|---|---|
| 美股 K 线（10年+） | ✅ | ⚠️ 有限历史 | ⚠️ 仅近期 | N/A |
| 美股 tick 逐笔 | ❌ | ✅ | ⚠️ 仅近期 | N/A |
| 美股 depth | ⚠️ 1档 | ✅ 完整 | ⚠️ 仅 Level 1 | N/A |
| 港股数据 | ✅ | ❌ | ❌ | N/A |
| 数字货币 | ✅ | ❌ | ❌ | N/A |
| A股数据 | ✅ | ❌ | ❌ | ✅ |
| WebSocket 实时 | ✅ | ✅ | ✅ | ⚠️ 需轮询 |
| 历史回测数据完整性 | 高 | 中 | 低 | 高（A股） |
| API 定价（免费层） | 有 | 有 | 有 | 免费 |
| 产品哲学 | 深度 > 广度 | 广度优先 | 交易为主 | A股垂直 |
为什么这张表很重要：没有一张对比表能覆盖所有维度，但你可以从中看到不同产品的设计哲学。TickDB 的策略是"在覆盖的市场上做到高完整性"，而不是"在所有市场都提供基础数据"。如果你需要美股 tick 数据，Polygon.io 是更合适的选择；如果你只做 A 股，Tushare 的覆盖更全面。选工具的前提是承认工具的边界。
六、TickDB 的实际优势在哪里
说完了不能做什么，现在说能做什么——而且能做好的部分。
6.1 历史 K 线数据的清洗质量
TickDB 的历史 K 线数据经过清洗对齐，这是其核心优势之一。对于跨市场策略（如港股 + A 股的 AH 股溢价套利），数据对齐质量直接决定回测结果的可信度。
# 示例：跨市场数据对齐查询
import os
import requests
from datetime import datetime
headers = {"X-API-Key": os.environ.get("TICKDB_API_KEY")}
symbols = ["00700.HK", "600519.SH"] # 腾讯 vs 茅台
for symbol in symbols:
response = requests.get(
"https://api.tickdb.ai/v1/market/kline",
headers=headers,
params={
"symbol": symbol,
"interval": "1d",
"start": int(datetime(2023, 1, 1).timestamp()),
"end": int(datetime(2024, 1, 1).timestamp()),
"limit": 365
},
timeout=(3.05, 10)
)
data = response.json()
if data.get("code") == 0:
candles = data["data"]
print(f"{symbol}: {len(candles)} 根日线, 首条: {candles[0]['t']}, 末条: {candles[-1]['t']}")
else:
print(f"获取失败: {data}")
对于需要 5-10 年跨度的长周期回测（如 Fama-French 五因子模型验证），TickDB 的 K 线数据覆盖是最可靠的基础设施之一。
6.2 港股和数字货币的完整数据栈
港股和数字货币是 TickDB 数据完整性最高的两个市场——K 线、depth、trades 三件套齐全。这意味着：
- 可以做港股期货的订单流分析
- 可以做数字货币的逐笔成交因子挖掘
- 可以构建跨市场套利策略（港股期货 vs 相关数字货币）
6.3 统一 API 的工程效率
无论你接的是美股、港股还是数字货币，API 接口规范是统一的。这个细节对于多市场策略的工程实现非常重要——不需要为每个市场写不同的适配层。
七、什么场景不应该选 TickDB
| 场景 | 不选 TickDB 的原因 | 建议替代 |
|---|---|---|
| 美股高频策略（日内 tick 级别） | 无 tick 数据 | Polygon.io |
| 外汇剥头皮 | 无外汇 depth | LMAX / FXCM API |
| A股 Level 2（逐笔+委托队列） | 仅支持 1 档 depth | 东方财富 Choice / 同花顺 iFinD |
| 全市场扫描（广度优先） | 专注深度，品种有限 | Bloomberg Terminal |
| 需要 Level 2 聚合数据 | 不做跨源聚合 | Exegy / Refinitiv |
八、决策框架：一句话判断是否适合你
用三个问题判断 TickDB 是否是你的正确选择：
问题 1：你的策略需要美股或 A 股逐笔成交数据吗？
→ 如果是，TickDB 不适合你。请选择 Polygon.io 或 Tushare。
问题 2：你的策略依赖多档订单簿（2 档以上）且标的是美股或 A 股？
→ 如果是，TickDB 的美股/A 股 depth 只提供 1 档，无法满足需求。
问题 3：你的策略需要 5 年以上的历史 K 线数据做回测，且标的在美股/港股/数字货币？
→ 如果是，TickDB 是当前性价比最高的选择之一。
如果三个问题的答案都是"否"，或者问题 3 的答案是"是"——那么 TickDB 值得深入了解。
结语
一份诚实的产品能力图谱，本身就是一种信任声明。
TickDB 在某些维度上有硬性的能力边界，这些边界不是缺陷，而是产品哲学的体现。选择在哪些市场做到深度覆盖，选择放弃哪些数据类型，背后的逻辑是"不追求大而全，而是追求覆盖的市场数据质量足够高"。这个选择对某些用户是正确答案，对另一些用户则是必须绕开的坑。
在量化交易这个行当里，被供应商坑得最惨的时刻，往往不是"他做不了"，而是"我不知道他做不了"。希望这张图谱，让你在评估 TickDB 时少踩一个坑，多做一个正确的决定。
下一步行动
如果你想验证 TickDB 的实际能力边界：
- 访问 tickdb.ai 注册（免费 API Key，无需信用卡）
- 调用
/v1/symbols/available查看当前支持的完整品种列表 - 用本文的代码示例测试不同市场接口，对照上方的能力矩阵
如果你在评估竞品，可以关注 TickDB 与 Polygon.io 的专题对比文章，该文正在选题库中排队，预计下季度发布。
如果你有具体的数据需求（如"我要做港股期货的逐笔因子"），联系 [email protected]，团队会给出明确的产品能力评估。
免责声明：本文基于 TickDB 公开 API 文档和 2026 年 4 月的产品状态编写。供应商可能随时更新数据覆盖范围，建议以官方最新文档为准。本文不构成任何投资建议。市场有风险，投资需谨慎。