价格是结果，订单簿是原因：理解市场微观结构的 5 个层次

---

你在屏幕前看到的是一根阳线：收盘价高于开盘价，涨幅 2.3%，一根再普通不过的日 K 线。

但如果你在那一刻打开订单簿，你会看到完全不同的景象：某机构正在悄悄撤掉价值 8000 万美元的卖单，同时在买一档挂入 200 万股——他们的目标根本不是收盘价，而是你在 K 线里根本看不到的信息优势。

K 线是历史的墓碑，订单簿才是活着的战场。

本文拆解市场微观结构的五个层次，从最基础的报价结构到最隐蔽的订单欺诈模式。每一个层次都对应着可量化的指标和可回测的策略逻辑。

---

第一层：报价结构——世界不是连续变化的

1.1 什么是订单簿

订单簿（Order Book）是交易所记录的某一时刻所有未成交买卖单的队列。它不是价格本身，而是价格形成之前的博弈场。

每一笔挂单都是一份要约：买家愿意支付的价格（Bid），卖家愿意接受的价格（Ask）。两者之间的差距，就是买卖价差（Bid-Ask Spread）。

订单簿快照示例（某做市商品种）：

卖五  142.35   500 股
卖四  142.33   1,200 股
卖三  142.31   800 股
卖二  142.30   2,100 股
卖一  142.28   650 股
-------------------------
买一  142.27   900 股
买二  142.25   1,800 股
买三  142.23   600 股
买四  142.21   2,400 股
买五  142.18   1,100 股

当前价：142.27（买一价）
买卖价差：0.01（142.28 - 142.27）
价差率：0.007% （0.01 / 142.27）

1.2 价差的本质

价差不是摩擦成本，而是流动性供应商的风险溢价。

想象你是做市商：你手里有股票，你愿意把它卖给下一个买家，但你需要补偿以下风险：

1. 库存风险：如果你刚买了大量股票，价格继续下跌怎么办？
2. 信息风险：你的交易对手知道什么你不知道的东西？
3. 逆向选择风险：跟你成交的人是否比你更聪明？

价差越大，说明市场越需要这种保护。在一只日成交额不足 100 万美元的僵尸股票里，价差可能高达 1%——这不是“庄家收割”，而是流动性稀缺时的合理定价。

1.3 价差的量化表达

指标	计算公式	经济含义
绝对价差	Ask - Bid	市场报价的绝对距离
相对价差	(Ask - Bid) / MidPrice	价差占中间价的比例，便于跨标的对比
有效价差	2 × |成交价 - 中间价|	衡量实际成交价格的偏离
实现价差	2 × |买入价 - 卖出价| / (买入价 + 卖出价)	衡量订单执行的实际成本

Python 实现：价差计算
"""

def calculate_spread_metrics(order_book):
    """
    计算订单簿的价差指标
    
    Args:
        order_book: dict, 包含 bids 和 asks 列表，每项为 (price, volume)
    """
    best_bid = order_book['bids'][0][0]  # 买一价
    best_ask = order_book['asks'][0][0]  # 卖一价
    mid_price = (best_bid + best_ask) / 2  # 中间价
    
    absolute_spread = best_ask - best_bid
    relative_spread = absolute_spread / mid_price
    
    return {
        'best_bid': best_bid,
        'best_ask': best_ask,
        'mid_price': mid_price,
        'absolute_spread': absolute_spread,
        'relative_spread': relative_spread,
        'spread_bps': relative_spread * 10000  # 基点表达
    }

---

第二层：深度结构——冰山之下的体积

2.1 订单簿深度不是简单的相加

新手常犯的错误：把“买一 + 卖一”的量相加当成市场深度。这忽略了两个关键事实：

1. 价格层级不是均匀分布的：卖一和卖二之间可能隔着 0.05 元，也可能隔着 2 元
2. 档位流动性差异巨大：越靠近买一/卖一的位置，挂单量越大，流动性越好

更精确的指标是累计深度（Cumulative Depth）：从当前价格往里走 n 档，总共有多少量可以成交。

累计深度计算示例：

档位    买价    挂单量    累计量
1       142.27   900       900
2       142.25   1,800     2,700
3       142.23   600       3,300
4       142.21   2,400     5,700
5       142.18   1,100     6,800

前 5 档累计买入量：6,800 股
前 3 档累计买入量：3,300 股

2.2 深度倾斜度：多空力量的温度计

深度倾斜度（Depth Tilt）是订单簿分析中最有价值的派生指标之一。它衡量买卖两侧的累积深度是否对称。

深度倾斜度 = (前 N 档买方累计量 - 前 N 档卖方累计量) / (前 N 档买方累计量 + 前 N 档卖方累计量)

• 值接近 +1：买方深度远大于卖方，说明市场有向上攻击的潜在能量
• 值接近 -1：卖方深度远大于买方，说明市场有向下打压的潜在能量
• 值接近 0：两侧均衡，趋势动能不足

但要注意：深度是静态的，挂单是可以撤的。大量挂单存在不等于这些单子真的会成交——这是第三层要解决的问题。

2.3 深层挂单的博弈逻辑

为什么主力资金愿意在深层挂大量卖单，但从不真的让它们成交？

答案：挂单本身就是信号。

当你看到卖三位置挂着 50,000 股，你的第一反应可能是“有大单要出货”。这种预期会影响你的决策——你可能更倾向于做空，或者提前卖出。

这种信息效应比实际成交更重要。即使这 50,000 股最终被撤销，庄家已经用零成本完成了“市场预期管理”。

这就是为什么挂单行为分析（Order Flow Toxicity）比单纯的深度分析更能揭示资金意图。

---

第三层：订单动态——挂单与撤单的战争

3.1 订单生命周期的四个阶段

订单状态流转：

[挂单] → [等待] → [部分成交/全部成交] → [完成]
            ↓
          [撤单]

每一笔挂单进入订单簿后，有两种命运：成交，或者被撤销。撤单率（Cancel-to-Trade Ratio）是衡量市场健康度的重要指标。

撤单率区间	市场状态	可能原因
< 5%	高度诚实	大幅波动前的平静期
5%-20%	正常范围	正常流动性补充
20%-50%	偏高	短期资金试探、钓鱼单
> 50%	极高	可能有冰山订单或市场操纵

3.2 订单流毒性：谁在污染流动性

不是所有订单都一样“干净”。有些订单进来就是为了被当作“燃料”消耗掉——真正的资金根本不打算在那个价格成交。

订单流毒性（Order Flow Toxicity）的衡量维度：

1. 成交驱动力：买单驱动的价格上涨 vs 卖单驱动的价格下跌
2. 被动成交比例：以限价单（被动）成交 vs 市价单（主动）成交
3. 订单寿命分布：平均挂单时长

计算被动成交比率（Passivity Ratio）：

被动成交率 = 被动成交量 / 总成交量

其中：
- 被动成交 = 限价单被对方吃掉（挂买一被成交）
- 主动成交 = 主动去吃掉对方挂单（买入价 = 卖一或更高）

被动成交率越高，说明资金越有耐心，愿意等待价格朝自己有利的方向移动。

3.3 TickDB 实时订单簿订阅

要实时捕捉订单簿变化，需要持续订阅交易所的增量推送，而非轮询快照。以下是生产级的 WebSocket 订阅代码：

"""
TickDB WebSocket 实时订单簿订阅
包含心跳保活、指数退避重连、限频自适应处理
"""

import os
import json
import time
import random
import threading
import websocket
from collections import deque


class OrderBookSubscriber:
    """订单簿实时监控订阅器"""
    
    def __init__(self, symbol, api_key, depth=10):
        self.symbol = symbol
        self.api_key = api_key
        self.depth = depth
        
        # 订单簿状态（滑动窗口，保留最近 100 帧）
        self.order_book_history = deque(maxlen=100)
        
        # 连接参数
        self.base_url = "wss://stream.tickdb.ai/v1/market/ws"
        self.ws = None
        self.retry_count = 0
        self.max_retries = 10
        self.base_delay = 1
        self.max_delay = 60
        
        # 心跳参数
        self.ping_interval = 30
        self.last_pong_time = time.time()
        self.pong_timeout = 10
        
        # 限频处理
        self.request_count = 0
        self.window_start = time.time()
        self.rate_limit = 100  # 每秒最大请求数
        
        # 运行状态
        self.running = False
        self._lock = threading.Lock()
    
    def connect(self):
        """建立 WebSocket 连接"""
        url = f"{self.base_url}?api_key={self.api_key}&symbol={self.symbol}&channel=depth_{self.depth}"
        
        self.ws = websocket.WebSocketApp(
            url,
            on_message=self._on_message,
            on_error=self._on_error,
            on_close=self._on_close,
            on_open=self._on_open
        )
        
        # 启动接收线程
        self.running = True
        thread = threading.Thread(target=self._run, daemon=True)
        thread.start()
        
        print(f"[TickDB] 已连接到 {self.symbol} 的 depth 频道")
    
    def _run(self):
        """WebSocket 接收循环（带心跳检测）"""
        while self.running and self.ws:
            try:
                self.ws.run_forever(ping_interval=self.ping_interval)
            except Exception as e:
                print(f"[TickDB] 连接异常: {e}")
                self._reconnect()
    
    def _on_open(self, ws):
        """连接建立回调"""
        self.retry_count = 0
        print(f"[TickDB] WebSocket 已打开")
    
    def _on_message(self, ws, message):
        """消息处理回调"""
        try:
            data = json.loads(message)
            
            # 处理心跳响应
            if data.get("type") == "pong":
                self.last_pong_time = time.time()
                return
            
            # 处理限频响应
            if data.get("code") == 3001:
                retry_after = int(data.get("retry_after", 5))
                print(f"[TickDB] 请求超限，等待 {retry_after} 秒")
                time.sleep(retry_after)
                return
            
            # 处理订单簿更新
            if data.get("type") == "depth_update":
                self._process_depth_update(data)
            
            # 手动心跳（备用）
            self._send_ping()
            
        except json.JSONDecodeError:
            pass
    
    def _send_ping(self):
        """发送心跳 ping"""
        if self.ws and self.ws.sock:
            try:
                self.ws.send(json.dumps({"cmd": "ping"}))
            except Exception:
                pass
    
    def _process_depth_update(self, data):
        """处理订单簿深度更新"""
        bids = data.get("data", {}).get("bids", [])
        asks = data.get("data", {}).get("asks", [])
        
        timestamp = time.time()
        
        # 计算关键指标
        best_bid = float(bids[0][0]) if bids else 0
        best_ask = float(asks[0][0]) if asks else 0
        mid_price = (best_bid + best_ask) / 2 if best_bid and best_ask else 0
        
        # 累计深度（前 N 档）
        bid_depth = sum(float(b[1]) for b in bids[:self.depth])
        ask_depth = sum(float(a[1]) for a in asks[:self.depth])
        
        # 买卖压力比
        pressure_ratio = bid_depth / ask_depth if ask_depth > 0 else 0
        
        # 价差
        spread = (best_ask - best_bid) / mid_price if mid_price > 0 else 0
        
        snapshot = {
            "timestamp": timestamp,
            "best_bid": best_bid,
            "best_ask": best_ask,
            "mid_price": mid_price,
            "bid_depth": bid_depth,
            "ask_depth": ask_depth,
            "pressure_ratio": pressure_ratio,
            "spread_bps": spread * 10000
        }
        
        with self._lock:
            self.order_book_history.append(snapshot)
        
        # 实时打印（生产环境可改为日志或告警）
        print(f"[{time.strftime('%H:%M:%S')}] "
              f"Bid:{best_bid:.2f} Ask:{best_ask:.2f} "
              f"Depth:{bid_depth:.0f}/{ask_depth:.0f} "
              f"Pressure:{pressure_ratio:.3f}")
    
    def _on_error(self, ws, error):
        """错误回调"""
        print(f"[TickDB] WebSocket 错误: {error}")
        self._reconnect()
    
    def _on_close(self, ws, close_code, close_msg):
        """连接关闭回调"""
        print(f"[TickDB] 连接关闭: {close_code} - {close_msg}")
        self._reconnect()
    
    def _reconnect(self):
        """指数退避重连（带抖动）"""
        if self.retry_count >= self.max_retries:
            print("[TickDB] 重连次数超限，停止重试")
            return
        
        self.retry_count += 1
        delay = min(self.base_delay * (2 ** self.retry_count), self.max_delay)
        # 添加抖动，避免惊群效应
        jitter = random.uniform(0, delay * 0.1)
        wait_time = delay + jitter
        
        print(f"[TickDB] {wait_time:.2f} 秒后尝试第 {self.retry_count} 次重连...")
        time.sleep(wait_time)
        
        self.running = True
        self.connect()
    
    def calculate_pressure_trend(self, window=20):
        """
        计算买卖压力比的滑动趋势
        
        Args:
            window: 样本窗口大小
        """
        with self._lock:
            history = list(self.order_book_history)
        
        if len(history) < window:
            return None
        
        recent = [h['pressure_ratio'] for h in history[-window:]]
        
        return {
            'current': recent[-1],
            'mean': sum(recent) / len(recent),
            'max': max(recent),
            'min': min(recent),
            'trend': 'bullish' if recent[-1] > recent[0] else 'bearish'
        }
    
    def close(self):
        """关闭连接"""
        self.running = False
        if self.ws:
            self.ws.close()


# 使用示例
if __name__ == "__main__":
    API_KEY = os.environ.get("TICKDB_API_KEY")
    
    if not API_KEY:
        raise ValueError("请设置环境变量 TICKDB_API_KEY")
    
    subscriber = OrderBookSubscriber(
        symbol="BTC.USDT",
        api_key=API_KEY,
        depth=10
    )
    
    try:
        subscriber.connect()
        
        # 持续监控 60 秒
        start_time = time.time()
        while time.time() - start_time < 60:
            time.sleep(5)
            
            trend = subscriber.calculate_pressure_trend(window=20)
            if trend:
                print(f"\n[趋势分析] {trend['trend']} | "
                      f"当前压力:{trend['current']:.3f} | "
                      f"均值:{trend['mean']:.3f}")
    
    except KeyboardInterrupt:
        print("\n[TickDB] 收到中断信号，正在关闭...")
    finally:
        subscriber.close()

⚠️ 工程提醒：高频交易场景下，建议将 _process_depth_update 改为异步处理（使用 aiohttp 或 asyncio），避免 GIL 锁成为吞吐量瓶颈。同时，订单簿历史建议存储在内存数据库（如 Redis）中，以便后续做订单流因子回测。

---

第四层：信息不对称——谁知道你不知道的事

4.1 订单簿泄露的机密

订单簿本身不会说话，但它的变化模式会泄露信息。

典型场景：某大型机构准备在 10:00 买入 500 万股某股票。在实际操作之前，他们会分批挂单——先挂 50 万股试探市场反应，再根据盘口变化调整策略。

如果你能观察到：

• 买一档挂单量突然增加 10 倍
• 但价格并没有上涨
• 撤单速度极快

这可能就是机构试探盘的信号。

4.2 冰山订单：隐形的巨兽

冰山订单（Iceberg Order）是机构常用的掩护手段：对外显示的只是一个小量（如 1,000 股），但总订单量可能是 100,000 股——剩余部分对市场隐藏，逐次释放。

冰山订单示意图：

对外显示：  卖一  142.28   1,000 股
真实挂单：  卖一  142.28   100,000 股

成交后，下一笔 1,000 股自动补入，直到 100,000 股全部成交或被撤销。

现代交易所（NYSE、NASDAQ、深交所）都支持冰山订单协议。在 TickDB 的深度频道中，你看到的卖一量 1,000 股可能就是冰山一角。

4.3 Spoofing：挂单欺诈的识别逻辑

Spoofing（虚假挂单）是一种市场操纵行为：交易者在卖盘挂大量卖单制造下跌假象，等价格下跌后撤销卖单、反手做多。

识别 Spoofing 的量化方法：

识别规则：
1. 某档位挂单量突然增加到平均值的 5 倍以上
2. 该挂单在价格朝不利方向移动后 5 秒内被撤销
3. 撤销后，价格迅速回归原位

Python 实现：简化版 Spoofing 检测
"""

def detect_spoofing(order_book_history, threshold=5.0, time_window=5):
    """
    检测虚假挂单模式
    
    Args:
        order_book_history: 订单簿历史快照列表
        threshold: 挂单量异常倍数阈值
        time_window: 价格变动后的观察窗口（秒）
    """
    alerts = []
    
    for i in range(1, len(order_book_history)):
        prev = order_book_history[i-1]
        curr = order_book_history[i]
        
        # 检测卖盘异常挂单
        prev_ask_vol = prev.get('ask_depth', 0)
        curr_ask_vol = curr.get('ask_depth', 0)
        
        if prev_ask_vol > 0:
            vol_ratio = curr_ask_vol / prev_ask_vol
            
            if vol_ratio >= threshold:
                # 触发告警：关注后续价格变动
                alerts.append({
                    'timestamp': curr['timestamp'],
                    'type': 'ask_spike',
                    'vol_ratio': vol_ratio,
                    'price_before': prev['mid_price'],
                    'price_after': curr['mid_price']
                })
    
    return alerts

⚠️ 注意：上述检测逻辑是简化版本，生产环境中需要结合成交数据（Trades）交叉验证，并排除正常的流动性补充行为。Spoofing 检测通常需要机器学习模型辅助，且在监管层面需要交易所级别的数据支持。

---

第五层：生态博弈——订单簿之外的力量

5.1 四大玩家的利益矩阵

理解订单簿，不能只看盘面数字。要理解背后的利益博弈：

玩家	目标	行为模式
散户	短期盈利	追涨杀跌，被动成交多
机构	Alpha + 执行	大单拆细，算法执行
做市商	买卖价差收益	提供流动性，方向中性
高频交易商	套利 + 延迟套利	极低延迟，订单流预测

这四类玩家的行为会在订单簿上留下不同的“指纹”。

5.2 做市商的两难

做市商的核心任务是提供流动性——在买家来的时候做卖方，在卖家来的时候做买方。

但他们面临一个永恒的两难：逆向选择。

如果你挂出卖单后价格立刻上涨，说明跟你成交的那个人知道一些你不知道的事——你被“逆向选择”了。

反之，如果你挂出卖单后价格下跌，你成功卖出了，但你可能卖得太便宜了。

这种两难导致做市商必须动态调整价差：

• 市场平静时：价差收窄，积极提供流动性
• 市场波动时：价差扩大，保护自己免受逆向选择

5.3 订单簿与价格发现

K 线告诉你“发生了什么”，订单簿告诉你“为什么发生”。

价格发现机制：

1. 信息进入市场 → 聪明资金开始行动
2. 大额买卖单进入订单簿 → 价格开始承压/受撑
3. 其他参与者观察到盘口变化 → 跟随交易
4. 价格移动 → 形成新的 K 线

关键洞察：订单簿变化领先于 K 线变化。
这就是为什么纯粹的技术分析（只看 K 线）
在微观层面是滞后的。

---

第六层：订单簿因子——从观察到盈利

6.1 什么是订单簿因子

订单簿因子（Order Book Factor）是将订单簿特征量化为可回测的数学指标，用于预测短期价格走势。

常见的订单簿因子：

因子名称	计算方法	信号含义
买卖压力比	买方深度 / 卖方深度	>1 看多，<1 看空
价差变化率	(当前价差 - 历史均值) / 历史标准差	极端值预警
挂单量变化率	(当前档位量 - 前一时刻) / 前一时刻	资金动向
订单流不平衡	(主动买成交量 - 主动卖成交量) / 总成交量	机构行为
订单簿熵	Σ(p_i × log(p_i))，p_i 为各档位占比	市场不确定性

6.2 基于订单簿因子的交易逻辑

简单策略框架：

信号条件：
1. 买卖压力比突破 1.5（买方力量显著强于卖方）
2. 且价格位于日内支撑位上方
3. 且价差处于正常区间（非极端扩展）

开仓逻辑：
- 多头信号：Buy if pressure_ratio > 1.5 and price > day_low * 1.02
- 空头信号：Short if pressure_ratio < 0.67 and price < day_high * 0.98

止损逻辑：
- 基于订单簿：若买卖压力比反向突破 0.8，触发止损
- 避免使用固定点数止损，因为在流动性枯竭时无法成交

6.3 订单簿数据的获取与回测

对于回测和实时监控，你需要能同时获取当前订单簿快照和历史订单簿变化。

TickDB 提供了 depth 频道的实时 WebSocket 订阅（如前文代码所示），以及 kline 历史数据接口用于与订单簿信号交叉验证。

"""
获取 TickDB 历史 K 线数据进行因子回测
"""

import requests
import pandas as pd
from datetime import datetime, timedelta


def fetch_kline_history(symbol, interval, start_date, end_date):
    """
    获取历史 K 线数据
    
    Args:
        symbol: 交易品种，如 "BTC.USDT"
        interval: K 线周期，如 "1h", "4h", "1d"
        start_date: 开始日期 "YYYY-MM-DD"
        end_date: 结束日期 "YYYY-MM-DD"
    """
    api_key = os.environ.get("TICKDB_API_KEY")
    
    # 转换为时间戳
    start_ts = int(datetime.strptime(start_date, "%Y-%m-%d").timestamp())
    end_ts = int(datetime.strptime(end_date, "%Y-%m-%d").timestamp())
    
    url = "https://api.tickdb.ai/v1/market/kline"
    headers = {"X-API-Key": api_key}
    
    all_data = []
    
    # 分段获取（避免单次请求数据量过大）
    current_ts = start_ts
    
    while current_ts < end_ts:
        params = {
            "symbol": symbol,
            "interval": interval,
            "start_time": current_ts,
            "end_time": min(current_ts + 86400 * 30, end_ts),  # 每段最多 30 天
            "limit": 500
        }
        
        response = requests.get(
            url, 
            headers=headers, 
            params=params,
            timeout=(3.05, 10)  # 超时设置
        )
        
        if response.status_code != 200:
            raise RuntimeError(f"请求失败: {response.status_code}")
        
        data = response.json()
        
        if data.get("code") == 0:
            klines = data.get("data", {}).get("klines", [])
            all_data.extend(klines)
            
            if len(klines) < 500:
                break
            
            # 下一段的起始时间
            current_ts = int(klines[-1][0] / 1000) + 1
        else:
            raise RuntimeError(f"API 错误: {data}")
        
        # 限频处理
        if "Retry-After" in response.headers:
            time.sleep(int(response.headers["Retry-After"]))
    
    # 转换为 DataFrame
    df = pd.DataFrame(all_data, columns=[
        "timestamp", "open", "high", "low", "close", "volume", "turnover"
    ])
    
    df["datetime"] = pd.to_datetime(df["timestamp"], unit="ms")
    
    return df


# 使用示例
if __name__ == "__main__":
    df = fetch_kline_history(
        symbol="BTC.USDT",
        interval="1h",
        start_date="2025-01-01",
        end_date="2025-04-01"
    )
    
    print(f"获取 {len(df)} 条 K 线数据")
    print(df.head())

⚠️ 回测提醒：上述示例仅展示数据获取方式。完整的因子回测需要：1）建立订单簿特征与收益率的统计关系；2）考虑交易成本（滑点通常 0.05%-0.2%）；3）做样本外测试（避免过拟合）。建议使用 Backtrader 或 Zipline 等专业回测框架。

---

价值对比：订单簿数据为什么需要专业源

理解订单簿的前置条件是能稳定获取订单簿数据。以下是常见方案的对比：

能力维度	免费数据源	通用券商 API	TickDB
订单簿深度	通常 1 档	1-5 档	depth 频道，最多 50 档（视市场）
实时性	无或延迟 15 分钟	轮询延迟 1-5 秒	WebSocket 推送，<100ms
数据标准化	混乱，需大量清洗	中等	统一 Schema，历史数据对齐
覆盖市场	单一市场	取决于券商资质	数字货币、港股、美股（1档）
API 稳定性	无 SLA	有 SLA	生产级 SLA
WebSocket 支持	无	通常无	原生支持，含心跳重连

---

结语

订单簿是金融市场最诚实的器官。

K 线会骗人——主力可以用资金画线。消息会骗人——真假难辨，且定价早已完成。但订单簿的每一个报价、每一笔撤单、每一层深度变化，都是真金白银的博弈结果。

理解订单簿的五个层次，不是为了成为“庄家”，而是为了在这个信息不对称的战场里，少一点盲目，多一点概率优势。

对于量化开发者而言，订单簿数据是因子的富矿：买卖压力、深度失衡、挂单撤单模式，这些在 TickDB 的 depth 频道里都可以实时获取。关键在于，你是否有足够的工程能力把这些数据转化为可执行的信号。

---

下一步行动

如果你想亲手复现本文的订单簿分析：

1. 访问 tickdb.ai 注册（免费，无需信用卡）
2. 在控制台生成 API Key
3. 设置环境变量 TICKDB_API_KEY，复制本文代码即可运行

如果你在构建订单流因子或事件驱动策略，可以进一步了解 TickDB 的：

• depth 频道：实时订单簿深度推送（港股 10 档、数字货币 10 档）
• kline 接口：10 年级别历史 K 线数据，用于因子回测
• WebSocket SDK：支持 Python/JavaScript，含心跳、重连、限频处理

如果你习惯用 AI 辅助开发：在 AI 助手中搜索安装 tickdb-market-data SKILL，一句话获取 TickDB 数据接口封装代码。

---

风险提示：本文不构成任何投资建议。订单簿因子交易存在显著的执行风险、滑点风险和模型失效风险，历史回测结果不代表未来收益。