「要不要上 Level 2？」是行情選型裡最常見的糾結之一。它通常不是成本問題，而是能力焦慮——擔心沒有深度數據會「錯過什麼」。但 Level 2 的數據量、儲存成本與工程複雜度都遠高於 Level 1，買錯方向的代價很實在。
這篇文章給一個判斷框架：Level 2 到底解決什麼問題，以及什麼時候你其實不需要它。
Level 1 與 Level 2 的本質區別
| 維度 | Level 1 | Level 2 |
|---|---|---|
| 內容 | 最優買價、最優賣價、最新成交價、成交量 | 多檔買賣盤口，含各檔價格與掛單量 |
| 能回答的問題 | 現在成交在什麼價格 | 這個價格的成交能承接多大規模 |
| 數據量級 | 基準 | 顯著更高，隨檔位數量與更新頻率放大 |
| 更新頻率 | 較低 | 盤口每次變動都可能觸發更新 |
| 典型用途 | 行情展示、估值、信號生成 | 流動性評估、大單拆分、微觀結構研究 |
核心差異可以概括成一句話：Level 1 告訴你「價格是多少」，Level 2 告訴你「這個價格能吃下多少量」。
Level 2 真正解決的問題
只有三類問題必須用 Level 2 才能回答：
問題一：這筆單子會不會顯著推動價格
Level 1 只能看到最優價上的掛單量。如果你要成交的規模超過最優檔的掛單量，價格會向下一檔滑動，但 Level 1 無法告訴你滑到哪裡、總成本是多少。這是 Level 2 最不可替代的用途。
問題二：盤口是否真實
盤口掛單可能包含虛假流動性（掛單後快速撤單）。只看最優檔無法判斷這個報價是否穩固；多檔盤口的掛單分佈能提供更多線索。
問題三：微觀結構研究
訂單流不平衡、盤口壓力、價差動態等研究需要多檔數據。這類需求本身就要求 Level 2。
三類不需要 Level 2 的場景
反過來看，以下場景買 Level 2 通常是浪費：
- 行情展示與看板：用戶需要看價格與漲跌幅，不需要看五檔盤口。絕大多數面向普通用戶的行情界面用 Level 1 就夠了。
- 中低頻策略：按日或按小時決策的策略，最優價的信息量已經足夠，盤口深度不會改變信號。
- 估值與風控快照：組合估值、風險敞口計算用最新成交價即可，不需要盤口結構。
這三類的共同點是：決策不依賴「能成交多少」，只依賴「成交在什麼價格」。 只要滿足這一條，Level 2 就是過度採購。
成本不止是訂閱費
Level 2 的真實成本包含四塊，後三塊經常被忽略：
| 成本項 | 說明 |
|---|---|
| 訂閱費用 | 通常只在最高檔套餐開放 |
| 傳輸與處理 | 盤口更新頻率高，消息量遠大於 Level 1 |
| 儲存 | 多檔盤口的歷史數據體積顯著更大 |
| 工程複雜度 | 需要盤口重建、檔位對齊、異常盤口過濾等額外邏輯 |
其中工程複雜度最容易被低估。多檔盤口不是「多幾個字段」——它是狀態型的：你需要按序應用增量更新來重建盤口，處理亂序、缺口和快照對齊。這套邏輯的開發和維護成本往往超過訂閱費本身。
決策清單
回答以下問題，如果全部為「否」，就不需要 Level 2：
- 你的策略是否會下超過最優檔掛單量的單？
- 你是否需要評估「以當前價格能成交多少」而不只是「當前價格是多少」？
- 你是否需要判斷盤口報價的真實性（虛假流動性）？
- 你是否在做訂單流或微觀結構相關的研究？
- 你是否有團隊能維護盤口重建與異常過濾這套工程邏輯？
第 5 條是很多團隊的盲點：有能力消費 Level 2 數據，不等於有能力正確使用它。 如果沒人維護盤口重建邏輯，拿到多檔數據也只能當擺設。
Python：先用 Level 1 數據做一次需求驗證
在升級之前，可以用 Level 1 數據做一次粗略驗證：如果按最優價掛單量估算，你的目標單量已經頻繁超過最優檔，那 Level 2 才有意義。
import httpx
API_KEY = "your_api_key"
BASE = "https://api.tiqex.io/api/v1/market"
# 你的典型單量（以股數或合約數為單位）
TARGET_ORDER_SIZE = 5_000
def assess_depth_need(codes: list[str], order_size: int) -> None:
"""用 Level 1 的 bid/ask 量做一次粗篩，判斷是否需要 Level 2。"""
resp = httpx.get(
f"{BASE}/quote",
params={"codes": ",".join(codes)}, # 單次最多 50 個 codes
headers={"X-API-Key": API_KEY},
timeout=10,
)
rows = resp.json().get("data", [])
over = 0
for r in rows:
if r.get("unavailable"):
print(f"{r.get('code'):<12} 數據不可用，跳過")
continue
# Level 1 只給出最優檔量，用較小的一側作為保守估計
top_size = min(v for v in (r.get("bidSize"), r.get("askSize")) if v is not None) if (r.get("bidSize") or r.get("askSize")) else None
if top_size is None:
print(f"{r.get('code'):<12} 無盤口量字段，需人工確認")
continue
if order_size > top_size:
over += 1
print(f"{r.get('code'):<12} 單量 {order_size} > 最優檔 {top_size} → 需要深度")
else:
print(f"{r.get('code'):<12} 單量 {order_size} ≤ 最優檔 {top_size} → Level 1 足夠")
print(f"\n{over}/{len(rows)} 個標的會擊穿最優檔")
if over == 0:
print("結論：當前單量下 Level 2 不是必需品")
else:
print("結論：存在價格滑點風險，值得評估 Level 2")
assess_depth_need(["AAPL", "MSFT", "NVDA"], TARGET_ORDER_SIZE)
這段代碼的邏輯是：用「單量是否超過最優檔掛單量」作為是否需要深度的第一層篩選。 如果所有標的的最優檔都遠大於你的單量，Level 2 帶來的額外信息對你的決策沒有影響。
需要說明的是，盤口量字段的可用性取決於套餐權限與市場，如果返回為空說明當前權限下拿不到該字段，需要先確認接口的實際返回結構。
務實的結論
- 先用 Level 1 驗證需求：如果單量從未超過最優檔，Level 2 不解決問題。
- 明確觸發條件：把「單量超過最優檔」或「需要評估流動性」設為升級 Level 2 的明確觸發條件，而不是憑感覺升級。
- 先評估工程能力：盤口重建、檔位對齊與異常過濾的開發維護成本往往高於訂閱費。
- 混合使用：對少數需要深度的標的啟用 Level 2，其餘繼續用 Level 1。
常見問題
Level 2 數據一定比 Level 1 好嗎？
不是。Level 2 提供更多信息，但成本更高、工程複雜度更大。如果決策不依賴「能成交多少」，Level 1 的最優價信息已經足夠。
做高頻交易是不是必須用 Level 2？
高頻策略通常確實需要盤口深度，但前提是團隊有能力處理盤口重建、增量更新與異常過濾。如果缺少這套工程能力，拿到數據也無法正確使用。
Level 2 的盤口數據可以直接拿來用嗎？
不能直接使用。多檔盤口是狀態型數據，需要按序應用增量更新來重建，並處理亂序、缺口與快照對齊。這是 Level 2 最大的工程成本來源。
怎麼判斷我的單量是否真的需要深度？
用 Level 1 的最優檔掛單量做粗篩：如果你的典型單量頻繁超過最優檔掛單量，價格滑點風險顯著，才值得評估 Level 2。
可以只對部分標的啟用 Level 2 嗎？
可以，而且推薦。對流動性較差或單量較大的少數標的啟用深度數據，其餘標的繼續用 Level 1，是成本與效果的合理平衡。
下一步
先回答決策清單裡的五個問題，再決定是否升級。Level 1 與 Level 2 的概念差異見 Level 1 與 Level 2 對比；各套餐的市場權限與深度數據開放情況見 套餐定價；如果你在做流動性評估或大單拆分，可參考 交易平臺方案；盤口相關的字段定義見 多市場行情接口文檔。