選套餐時最容易犯的錯誤，是默認「實時一定比延遲好」。事實上，很多團隊每月多付幾百美元買來的實時數據，用在了根本不需要實時的場景上；而另一些團隊為了省錢選了延遲套餐，結果核心功能不可用。
判斷標準不應該是「哪個更高級」，而應該是你的業務決策週期有多長。
「延遲」到底意味著什麼
延遲行情指的是數據不是隨市場變化即時下發，而是經過一段時間後才可用。它與你熟悉的「實時行情」在數據結構上完全一致——同樣的字段、同樣的接口、同樣的格式，區別只在時效性。
這一點很重要，因為它意味著：從延遲切換到實時，不需要改代碼結構，只需要改套餐權限。 這也讓「先用延遲開發、上線前再升級」成為一種可行的策略。
怎麼在代碼裡判斷拿到的是不是延遲數據
不要靠假設，要靠字段。行情接口的響應裡帶有 delayed 布爾字段，為 true 時表示該數據當前是延遲的：
import httpx
resp = httpx.get(
"https://api.tiqex.io/api/v1/market/quote",
params={"codes": "AAPL,EURUSD,BTCUSDT"}, # 單次最多 50 個 codes
headers={"X-API-Key": "your_api_key"},
timeout=10,
)
body = resp.json()
for row in body["data"]:
flag = "延遲" if row.get("delayed") else "實時"
if row.get("unavailable"):
flag = "不可用"
print(f"{row['code']:<10} {flag} last={row.get('last')}")
把 delayed 與 unavailable 都納入判斷，可以避免一個常見事故：開發環境用免費套餐跑通，生產環境上線後發現某些市場其實是延遲的，而代碼裡沒有任何校驗。 建議在應用啟動時做一次自檢，把各市場的實時/延遲狀態打印出來，或直接對關鍵市場斷言必須為實時。
延遲數據足夠用的四類場景
- 歷史數據分析與可視化：只要數據最終一致，用於圖表、報表、趨勢分析時延遲完全不影響結論。
- 低頻策略與再平衡：按日或按周調倉的策略，決策週期以天計，秒級延遲毫無意義。
- 組合估值與風險快照：每日收盤後的估值、持倉核對、風險敞口計算，用延遲數據即可。
- 開發與測試：接口聯調、單元測試、CI 流水線驗證，延遲數據完全夠用，而且免費。
必須用實時數據的三類場景
- 交易執行與下單決策：價格是決策的直接輸入，延遲意味著按過時價格成交。
- 實時告警與風控：止損提醒、異常波動告警、風險閾值觸發，延遲會讓告警失去意義。
- 面向用戶的實時界面：交易終端、行情看板、投研工具。用戶能直接看到價格在跳，延遲數據會造成明顯的體驗落差和信任問題。
這三類的共同點是：延遲直接改變了決策結果或用戶感知。只要滿足這一條，就必須上實時。
按場景對照套餐
| 你的場景 | 所需權限 | 參考套餐 |
|---|---|---|
| 接口聯調、原型驗證 | 延遲即可 | Free |
| 歷史數據回填與報表 | 延遲即可 | Free / Growth |
| 加密與金屬的實時監控 | 實時（部分市場） | Growth |
| 跨市場實時看板（股票 + 外匯 + 加密） | 全市場實時 | Pro |
| Level 2 深度與私有連接 | 全市場 Level 2 | Enterprise |
值得注意的一點是：不同套餐的市場權限是分檔的，不是簡單的「全延遲 / 全實時」。某個中間檔套餐可能讓加密與金屬實時，而股票、外匯、指數仍是延遲。所以選型時要按市場維度核對，而不是隻看套餐名稱。
混合方案：把實時額度花在刀刃上
如果預算有限但又有實時需求，常見的做法是混合使用：
- 關鍵標的走實時流式：只對需要實時決策的少數標的訂閱 WebSocket。
- 其餘走延遲查詢：非關鍵標的用 REST 定期拉取延遲數據。
- 前端明確標註數據時效：延遲數據在界面上加時間戳或標識，避免用戶誤判。
這樣既控制了成本，也避免了「全量實時」帶來的額度與流量壓力。需要注意 WebSocket 的訂閱數量受套餐約束，選型時要一併確認。
你的策略能容忍多少延遲
一個實用的判斷方法，是從決策週期反推延遲預算：
| 策略週期 | 決策頻率 | 有意義的延遲量級 |
|---|---|---|
| 高頻 / 做市 | 亞秒級 | 個位數毫秒 |
| 日內交易 | 秒級到分鐘級 | 一秒以內 |
| 每日調倉 | 每天一次 | 分鐘級 |
| 周度 / 月度配置 | 數天到數週 | 小時級 |
拿這張表對照你自己的決策頻率。如果最快的決策一天只發生一次，為毫秒級數據付費就是在買你永遠用不上的精度；如果最快的決策每秒都在發生，延遲數據會讓系統「算錯」，而不只是「慢一點」。
一個容易忽略的坑：延遲數據的緩存語義
延遲數據有個特性容易被忽略：同一時刻多次請求，返回的可能是同一個值。這意味著你在延遲模式下寫的緩存邏輯，切換到實時後會失效——因為實時數據的每次請求都可能返回新值。
典型症狀是：開發時緩存 60 秒看起來完全沒問題，上線切實時後用戶反饋「價格不動」。所以緩存策略必須與數據時效性匹配：延遲數據可以長緩存，實時數據應該走推送而不是輪詢 + 緩存。
常見問題
延遲數據會影響回測結果嗎？
會，但影響取決於策略週期。按日調倉的策略，延遲幾分鐘對結果影響極小；分鐘級或更短週期的策略，延遲會直接改變信號，回測結果不可信。
免費套餐的數據可以用來做什麼？
免費套餐覆蓋加密、美股與金屬的延遲數據，適合接口聯調、原型驗證、歷史數據回填和低頻分析。它的定位是讓你在零成本下跑通完整流程。
怎麼確認某個市場在我的套餐下是實時還是延遲？
兩種方式：查響應裡的 delayed 字段，或對照套餐的市場權限說明。建議在代碼裡對關鍵市場做斷言，避免上線後才發現是延遲數據。
可以先按延遲開發，之後再切實時嗎？
可以，而且推薦。延遲與實時的數據結構完全一致，切換隻需改套餐權限，不需要重構代碼。但要注意緩存策略需要相應調整。
Level 2 數據屬於哪一類？
Level 2 提供更深的訂單簿檔位，屬於更高權限的範疇，通常只在最高檔套餐開放。它和「實時 / 延遲」是兩個獨立的維度——Level 1 也可以是實時的。
延遲數據更便宜是因為質量更差嗎？
不是。底層是同一份數據源，區別只在於你什麼時候能拿到。延遲檔位更便宜，是因為數據的即時商業價值更低，而不是因為準確性更差。
下一步
先明確你的決策週期，再按市場維度核對權限。各套餐的市場覆蓋與實時 / 延遲劃分見 套餐定價；具體市場的權限說明可查閱 加密貨幣行情 與 美股行情 頁面；接口返回的 delayed 與 unavailable 字段定義見 多市場行情接口文檔；如果你在權衡訂單簿深度，可先看 Level 1 與 Level 2 對比。