WEEX API 相容性：從其他交易所遷移時有哪些變化

如果您已經為 Binance、OKX 或 Bitget 編寫了整合代碼，那麼您真正想了解的關於 WEEX 的只有一點：哪些可以複用，哪些必須重寫？本文不羅列接口，而是從三個維度探討 WEEX API 的相容性——身份驗證方式、ccxt 統一層以及現貨/合約版本控制——並以遷移時的決策清單作為結尾。重點在於實際操作中容易出錯的兩個環節：調用方式以及權限與金鑰的管理。

核心結論：WEEX 的身份驗證設計屬於 OKX / Bitget 系列（Base64 編碼的 HMAC 預簽名加口令），而非 Binance 的「查詢字串簽名」風格。掌握這一點，您就能準確評估遷移工作量。

「WEEX API 相容性」的實際含義

此處的「相容性」包含三個層面——切勿混淆：

• 身份驗證相容性——簽名演算法、請求頭和時間戳格式是否與您熟悉的交易所匹配，這決定了您的簽名模組是否需要重寫。
• 抽象層相容性——像 ccxt 這樣的統一庫是否允許一套代碼在不同平台運行。
• 內部版本相容性——WEEX 的現貨與合約、V2 與 V3 是否共享欄位和路徑，這決定了您在 WEEX 內部跨產品遷移時的投入。

確定您正在遷移的層面，然後閱讀下方的對比。

身份驗證相容性：WEEX 與 Binance、OKX 風格對比

這是任何遷移中最困難的部分。根據其 簽名文件，WEEX 構建一個 timestamp + method + path + body 的預簽名字串，運行 HMAC SHA256，對輸出進行 Base64 編碼，並通過四個 ACCESS-* 請求頭傳遞。下表對比了三種主流風格（WEEX 數據來自官方文件，截至 2026 年 7 月；其他均為各交易所廣泛記錄的公共慣例）：

解讀：從 OKX 或 Bitget 遷移到 WEEX，簽名邏輯幾乎可以直接複製——您只需重新命名請求頭。從 Binance 遷移則意味著重寫簽名模組——Binance 簽名查詢參數、輸出十六進位且無需口令，這與 WEEX 的 Base64 預簽名模型完全不同。同時，WEEX 使用毫秒級時間戳，這比 OKX 的 ISO 格式更接近 Binance，而這種細節往往是遷移中最容易被忽略的。

ccxt 能否實現 WEEX 開箱即用的相容性？

可以——這是規避身份驗證差異最輕鬆的方法。開源庫 ccxt 已經集成了 WEEX，涵蓋了現貨、合約（永續）和 WebSocket，支援 80 多種統一方法。如果您已經在其他平台運行 ccxt，遷移到 WEEX 基本只需更改類名和三個憑證欄位：

import ccxt

ex = ccxt.weex({
    "apiKey": "your-APIKey",
    "secret": "your-SecretKey",
    "password": "your-Passphrase",   # WEEX 口令 → ccxt "password"
})
print(ex.fetch_ticker("BTC/USDT"))

fetch_ticker、fetch_balance 和 create_order 在各平台間完全一致，因此業務層幾乎無需變動。需要注意的是，ccxt 是社群抽象庫：符號命名（BTC/USDT 與 BTCUSDT）、精度和手續費欄位由 ccxt 歸一化，但如果 WEEX 發布了新接口，ccxt 的覆蓋可能會滯後——在追求新功能時，請務必核對 WEEX API 簡介。

現貨與合約版本相容性 (V2 / V3 BETA)

當您跨產品操作時，WEEX 內部也存在相容性問題。現貨和合約 API 均處於 V3 (BETA)，合約同時保留了 V2。由此得出兩個結論：

• 現貨和合約共享相同的 ACCESS-* 身份驗證和 HMAC SHA256 + Base64 簽名，因此 身份驗證模組可在兩個產品線間複用——僅路徑和業務欄位不同。
• 合約同時運行 V2 和 V3 意味著遺留代碼可能仍在使用 V2。由於 V3 仍標記為 BETA，在生產環境發布前請確認您依賴的版本，並訂閱變更日誌，以免 BETA 欄位的變動讓您措手不及。

一言以蔽之：WEEX 的內部身份驗證相容性很強；您需要關注的是「BETA」狀態和版本遷移節奏。

遷移到 WEEX 需要更改哪些代碼

將其拆解為可操作的清單，工作量因來源而異：

無論來源如何，必須遵守三項 WEEX 特定設定：與伺服器偏差超過 30 秒的時間戳將被拒絕；公共接口每 2 秒允許約 20 次請求，超出將返回 HTTP 429；一般規則請參考 標準規範文件。

相容層安全嗎？權限與金鑰遷移注意事項

在跨交易所遷移中最容易被「遺忘」的是安全配置——舊平台上的鬆散習慣一旦帶到新金鑰上，就會成為隱患。WEEX 是否支援 API 交易及其官方安全指南，請參閱 WEEX API 交易說明。遷移期間，請核實：

• 重新最小化權限——WEEX 金鑰預設為 唯讀，交易權限需手動開啟；不要為了方便而開啟所有權限，也不要沿用舊平台「完全存取」的習慣。
• 重新綁定 IP 白名單——切換伺服器出口 IP 後，請重新綁定；WEEX 明確將未綁定 IP 的金鑰標記為風險。
• 口令是新欄位——從 Binance 遷移的團隊經常忘記 WEEX 需要一個遺失後無法找回的口令；請將其納入您的金鑰管理流程。
• 預設無提現權限——這限制了金鑰被盜後的損失，但這並非放鬆 SecretKey 管理的理由。

總結

WEEX API 相容性歸結為一句話：身份驗證屬於 OKX / Bitget 系列，ccxt 抹平了差異，現貨和合約內部共享一套簽名方案。從 ccxt 或同系列交易所遷移幾乎沒有痛苦；從 Binance 遷移主要是重寫簽名並添加口令。真正的額外投入不在於整合，而在於在新環境中重新配置安全設定（最小權限、IP 白名單、口令管理）。要開始動手對比，請從 WEEX API 簡介 開始。

延伸閱讀：ccxt 的 WEEX 方法覆蓋範圍請見其 官方維基。

常見問題解答

1. WEEX API 與 Binance API 相容嗎？

在簽名層面不相容。Binance 簽名查詢字串、輸出十六進位且無需口令；WEEX 預簽名 timestamp + method + path + body，HMAC SHA256 後輸出 Base64，且需要口令。從 Binance 遷移意味著重寫簽名模組。

2. WEEX API 與 OKX 或 Bitget 相容嗎？

非常接近。三者均使用 Base64 預簽名 + 口令風格，並帶有 ACCESS-* 請求頭，因此簽名邏輯基本可複用。主要區別在於 OKX 使用 ISO-8601 時間戳，而 WEEX 使用毫秒級 epoch。

3. ccxt 能否同時連接 WEEX 和其他交易所？

可以。ccxt 已經集成了 WEEX（現貨、合約、WebSocket），相同的 fetch_ticker、create_order 等方法適用於各平台——切換交易所只需更改實例化的類和憑證。

4. WEEX 現貨和合約能否共享一套身份驗證代碼？

可以。兩個產品線使用相同的 ACCESS-* 請求頭和 HMAC SHA256 + Base64 簽名，因此身份驗證模組可複用；僅請求路徑和業務欄位不同。兩者均處於 V3 (BETA)，合約同時支援 V2。

5. 遷移到 WEEX 時最容易遺漏的安全項目是什麼？

三項：未重新綁定 IP 白名單；從 Binance 等無需口令的平台遷移時漏掉口令；沿用「完全存取」金鑰。WEEX 金鑰預設為唯讀且無提現權限，請相應地縮減至最小權限。

風險提示

數位資產波動劇烈，透過 API 進行自動化或跨交易所交易可能因策略缺陷、劇烈市場波動或系統故障導致部分或全部資本損失。遷移和多平台設定增加了特定風險：簽名或時間戳配置錯誤可能導致訂單失敗或重複；未綁定 IP 的金鑰洩漏可能讓攻擊者操作您的帳戶；依賴 ccxt 等第三方抽象庫意味著其欄位映射或版本滯後可能與交易所實際行為不符；合約槓桿會放大損失。請應用最小權限原則，為每個平台重新配置 IP 白名單和口令，並在生產環境前使用小額資金驗證相容性。本文為技術對比，不構成投資建議。