訂閱機制

交易推送採用連接即訂閱模型：客戶端完成 WebSocket 連接和登錄鑑權後，服務端會自動推送當前鑑權用戶的交易事件，無需客戶端發送額外的訂閱請求。

與行情推送的區別

行情推送需要客戶端顯式聲明訂閱的標的和數據類型；交易推送則不同：

維度	行情推送	交易推送
訂閱方式	顯式訂閱，需指定標的代碼和數據類型	隱式訂閱，鑑權後自動生效
推送範圍	僅推送已訂閱的標的和類型	推送鑑權賬戶下所有賬戶的全部事件類型
取消訂閱	可隨時反訂閱	斷開連接即停止接收

事件覆蓋範圍

鑑權成功後，客戶端將自動接收以下全部事件類型，無法單獨過濾某類事件：

事件類型	說明
EVENT_NEW	下單成功
EVENT_REPLACED	改單成功
EVENT_CANCELED	撤單成功
EVENT_EXPIRED	訂單過期
EVENT_FILL	成交事件（含部分成交和全部成交）
EVENT_NEW_REJECTED	下單失敗
EVENT_REPLACE_REJECTED	改單失敗
EVENT_CANCEL_REJECTED	撤單失敗
EVENT_FILL_CORRECT	成交修正
EVENT_FILL_CANCEL	成交撤銷

各事件的消息結構和字段說明詳見 數據格式。

賬戶維度說明

服務端按鑑權用戶的賬戶維度推送事件，即推送該用戶名下所有交易賬戶的事件。推送消息中的 user_info.acc_id 字段標識事件所屬的具體交易賬戶。如果同一用戶持有多個交易賬戶，所有賬戶的事件都會在同一連接上推送，客戶端應根據 acc_id 區分來源。

行為說明

事件推送時機

服務端在交易事件發生時實時推送，事件到達時間取決於網絡狀況和服務端處理延遲，不保證固定的推送間隔。

不補發歷史事件

連接斷開期間發生的交易事件不會在重連後補發。如需查詢歷史訂單或成交記錄，請使用以下 REST 接口：

• 獲取當日訂單 — 查詢當日委託訂單。
• 獲取當日成交 — 查詢當日成交記錄。
• 獲取歷史訂單 — 查詢歷史委託訂單。
• 獲取歷史成交 — 查詢歷史成交記錄。

重連後恢復

連接斷開並重新鑑權後，服務端會自動重新建立推送通道，繼續推送後續發生的事件。

客戶端實現建議

• 不要依賴推送作為唯一的狀態來源：推送適合實時通知，首次加載頁面或斷線後的狀態補齊，建議先調用 REST 接口查詢完整狀態。
• 處理重複事件：在極少數網絡抖動或服務端重試場景下，可能收到重複的事件推送。建議客戶端按 event_id 做冪等處理。
• 不要依賴事件順序：網絡抖動可能導致事件亂序到達。如需還原狀態，應以事件中的 order_status 和 event_time_us 等字段為準，而非推送順序。

下一步

• 登錄鑑權 — 了解鑑權流程。
• 連接保活 — 處理斷線和重連。
• 數據格式 — 查看事件消息的完整字段說明。