痛點浮現：正常的Tick，異常的K線
我做貴金屬高頻資料研究已經有幾年了，手上維護著一套自用的即時行情監控系統。某天在檢查歷史K線時，發現一個讓我很不踏實的現象：明明現貨黃金當天沒有重大消息，一分鐘K線卻接連出現好幾處莫名其妙的斷層，有的是兩根K線之間忽然空了一大段，有的是開盤價偏離前一根收盤價好幾個點，甚至有些時段的成交量像吹氣球一樣瞬間膨脹又消風。
一開始，我直覺認為是自己寫的K線聚合邏輯出了包。反覆檢查迴圈條件、邊界處理，甚至重構了兩次，結果問題依然照舊。後來把整天的tick資料全部倒出來，一條一條排好時間序來比對，才終於看出端倪：那些異常全部都集中在亞洲盤收尾、歐洲盤開工，或是歐美交接的「敏感時刻」。原來，程式碼沒有錯，錯的是我忽略了不同市場在時間軸上留下來的「時差腳印」。
跨市場時段為什麼會讓K線走樣
貴金屬是一個橫跨多個交易中心的品種，亞洲、歐洲、美洲輪流接棒，但這三個區域的交易節奏完全不一樣。每次市場換手的時候，tick 數量、報價頻率都會有明顯變化。例如在交接重疊階段，行情可能瞬間活躍起來，短時間內湧入大量資料；等到某個區域收盤後，更新速度又會忽然慢下來。
如果我的程式只是傻傻地按照「資料抵達的順序」來切K線，就很容易把這些正常的市場節奏變化，誤判成資料異常或缺失。下表是我整理出來，那段時間最常碰到的幾種情況：
| 異常類型 | 表現 |
|---|---|
| 時間間隔異常 | K線之間出現較長空檔 |
| 價格連接異常 | 新K線開盤價偏離上一根收盤價 |
| 成交量變化異常 | 某些時間段資料突然增加或減少 |
| 重複行情 | 同一時間出現多條相同數據 |
這些現象本身不一定代表資料有錯，而是需要結合市場時段與行情狀態一起判讀，才能分辨哪些是真的問題、哪些只是市場本身的特性。
研究者的資料需求：我要的是一個穩定不飄移的時間軸
經歷這一輪折騰，我更加確定，做金融學術研究或是為機構建置資料庫的時候，最關鍵的需求不是資料有多「快」，而是時間序有多「穩」。不同資料源、不同市場的每一筆tick，都必須被統一到同一個時間基準上，否則後續的波動率模型、日內型態辨識、事件研究等，全都有可能因為時間軸的輕微偏移而失準。
具體來說，我需要一個具備高精度時間戳、並且能讓我在接收端自由轉換成UTC的行情來源。只有先把所有行情都拉到同一條時間軸上，K線的邊界才能做到真正統一。
解法一：用UTC強制對齊，不讓時區扯後腿
我後來的處置方法很明確：不管行情API回傳的是UTC、倫敦時間還是紐約時間，所有資料進到系統的第一站，就是強制轉成UTC。接著，K線的切割窗口完全以UTC整分鐘為邊界，像這樣：
- 12:00:00 – 12:00:59
- 12:01:00 – 12:01:59
- 12:02:00 – 12:02:59
如此一來，來自不同市場的tick都會乖乖掉進同樣的時間籃子裡。這個「統一時間基準」的動作，直接讓我的K線結構穩定下來，也從根源上消滅了因時區變換而產生的錯位。
解法二：K線生成前，先過安檢
除了時間格式統一，我也改掉「收到tick就直接拿來畫K線」的習慣。現在每一筆tick要進入聚合程序之前，都會先經過一個輕量的連續性檢查。
舉個例子，前一筆行情時間是： 2026-07-28 14:20:01
下一筆卻變成： 2026-07-28 14:25:30
中間出現將近五分鐘的間隔時，我不會立刻判定為異常，而是會先判斷：這段時間是不是本來就屬於低流動性時段（像亞洲午盤）？如果是，那這樣的間隔完全合理；如果不是，在流動性充沛的時段出現這麼大的空白，才比較有可能是資料掉包或推送延遲。
價格變化的檢測也是同樣邏輯。短時間內若出現明顯偏離正常波動範圍的價格，程式會先標記起來，但不會讓它直接影響K線的計算結果，等後續人工或自動化複查再來確認。
另外，所有未經加工的原始tick，我一定會完整保留。將來任何一根K線被懷疑有問題時，都可以直接拿原始資料重新產生一遍，而不必去修改已經畫好的圖形。這種回溯重建的能力，對學術研究或需要供第三方驗證的情境來說，實在太重要了。
即時行情處理：WebSocket接手，時間轉換擺第一
在進行即時貴金屬行情處理時，我已經全面改用WebSocket來取代定時輪詢。持續的長連線推送不只延遲更低，也能最大程度保持tick的原始順序，對跨市場時段處理特別有幫助。像我自己目前在用的行情API，就是透過WebSocket即時送出tick資料，每一筆訊息裡都會夾帶時間戳。我的on_message處理函式中，第一件事情就是將那個時間戳轉成UTC，然後才往後丟給K線引擎。
以下是實際在跑的接收端程式碼（註解已經換成中文，比較好對照）：
import websocket
import json
from datetime import datetime, timezone
def on_message(ws, message):
data = json.loads(message)
symbol = data.get("symbol")
price = data.get("price")
timestamp = data.get("timestamp")
# 收到報價後立刻轉換為 UTC 時間
utc_time = datetime.fromtimestamp(
timestamp / 1000,
tz=timezone.utc
)
print(
"AllTick API",
symbol,
price,
utc_time
)
def on_open(ws):
subscribe = {
"action": "subscribe",
"symbol": "XAUUSD",
"type": "tick"
}
ws.send(json.dumps(subscribe))
ws = websocket.WebSocketApp(
"wss://api.alltick.co/ws",
on_open=on_open,
on_message=on_message
)
ws.run_forever()
從這段程式碼可以看出，關鍵動作並不是連線本身，而是那個 datetime.fromtimestamp 的時間標準化步驟。只要這個動作確實執行，後續K線生成階段的許多麻煩都會自然消失。
低流動性不是錯誤，別把安靜的市場當成故障
還有一個很容易踩到的誤區：在行情清淡的時段，tick數量本來就會變少，這不是資料品質不好。尤其在亞洲與歐洲交接的前後，成交稀疏、K線波動縮小，都可能是市場的常態。
如果監控程式只靠「tick數量夠不夠多」來判斷是否異常，就很容易把真實的市場況狀過濾掉。我現在在處理這一類判斷時，會同時從四個面向來看：
- 時間戳是否連續
- 價格變化是否在合理範圍內
- 資料本身是否完整
- 當下是否處於跨市場切換階段
四個條件綜合起來，就能讓系統既能揪出真正的資料問題，又不會錯殺正常的低流動性行情。
學術價值：把時間治理好，研究才有說服力
老實說，經過這段時間的實戰，我越來越覺得，K線的品質固然跟資料源有關，但更大的影響因子其實是「後續的處理方式」。貴金屬這種跨市場品種，本身就是由好幾個區域的流動性拼湊出來的，如果能在時間統一、異常檢測和原始資料保存這三個環節都做好，後面不管是要跑計量模型、做回測，還是發paper時的穩健性檢驗，底氣都會完全不一樣。
行情資料進入系統，只是一切的起點。如何讓這些資料在不同的市場節奏底下，依然保持連續、可靠，才是建構一個足以支撐學術研究與實務判斷的行情系統，最核心的所在。
