交易所 API 對接常見的坑，你踩過幾個

做量化交易系統開發，交易所 API 對接是繞不開的一環，也是最容易被低估工作量的一環。表面上看，無非是幾個 REST 介面下單查單，加一個 WebSocket 訂閱行情，實際做下來會發現細節非常多。 第一個坑是限流（rate limit）。幾乎所有交易所都對介面呼叫頻率有限制，而且往往按不同介面分別計算權重，下單、撤單、查詢各自佔用不同的額度。如果沒有做好請求節流與排隊機制，高頻呼叫時很容易被限流甚至暫時封鎖IP或API Key，這一點在壓力測試階段就要提前驗證。 第二個坑是訂單狀態的最終一致性。下單請求回傳成功，不代表訂單已經被撮合引擎處理完成；訂單從被交易所接受到真正成交或被拒絕，中間存在時間差，而且REST查詢與WebSocket推播的狀態更新可能不同步。系統設計上需要一個統一的訂單狀態機，以某個資料來源為準並妥善處理狀態回退與重複推播的情況。 第三個坑是斷線重連。WebSocket連線會因為網路波動、交易所主動中斷等原因斷開，重連之後必須重新訂閱，並且要有機制補齊斷線期間可能錯過的行情或訂單更新，否則系統會基於過期或不完整的資料做決策。 第四個坑是冪等性。網路逾時後到底要不要重試下單，是很容易出錯的地方——如果原本的請求其實已經成功，重試會導致重複下單。規範的做法是客戶端產生唯一訂單編號，交易所支援按此ID去重。 第五個坑是精度與最小變動單位規則。每個交易對的價格精度、數量精度、最小名目金額都不同，下單前必須按交易所規則對價格與數量做取整處理，否則訂單會被直接拒絕。 第六個坑是時鐘同步。許多交易所的簽章機制要求請求時間戳在一定誤差範圍內，伺服器時鐘漂移會導致請求被拒絕，需要定期做NTP校準。 這些問題單獨看都不複雜，但疊加起來就是對接穩定性的主要來源，值得在系統設計初期就投入足夠的測試與容錯設計。