OCO、OTO、OTOCO：先讀懂關聯訂單，再談自動化

條件單不是任何一家交易所的專有功能，而是一組通用的執行結構。最基礎的三種關聯方式，可以用「誰先動、誰後動、誰取消誰」來區分。第一種是二選一：兩張價格方向相反的訂單同時掛在市場上，任何一張成交就立刻撤銷另一張，用來一次佈置獲利了結與停損。第二種是先決後觸發：第一張訂單必須先完全成交，系統才會把第二張訂單送進市場；在此之前第二張只是待命狀態，不占用訂單簿，也不鎖定額外資金。第三種是先決後二選一：第一張訂單成交後，一次生出兩張互斥的後續訂單，等於把前兩種結構串接起來。先把這三個骨架記住，比背下任何一家的按鈕位置都有用。

各家交易所對這三種結構的命名並不一致。有的直接沿用 OCO、OTO、OTOCO 這類縮寫，有的叫「二擇一委託」「條件委託」「計劃委託」，也有的把它們拆成「止盈止損」與「觸發單」兩個入口。名稱不同不代表機制不同——只要問清楚三件事就能對上：哪一張訂單先進入撮合、後續訂單在什麼事件下被建立、哪一個事件會導致另一張被撤銷。這三個答案確定了，剩下的差異只是介面用語與參數名稱。本文接下來就以公開的 Spot 技術文件為核對基準，把這三個問題逐一落到具體欄位、狀態值與過濾器上，讓讀者能用同一套讀法去看任何一家的說明。

如果讀者還不能分辨 base asset、quote asset、BUY、SELL、Market、Limit，以及掛單與成交的差別，應先回到既有 Spot 教學。這篇只處理「多張訂單如何被一個關係規則連接」：哪一張先進入撮合、哪一張仍在等待、何時建立後續訂單、哪個事件會取消另一腿，以及失敗後要用哪些紀錄還原真實狀態。OCO、OTO、OTOCO 不是收益策略名稱，也不回答應買還是應賣；它們只是執行結構。把結構誤認成方向判斷，最容易產生錯誤安全感。

2026-08-09 的 Binance Spot API 目錄同時列出 New Order list - OCO、New Order List - OTO、New Order list - OTOCO。這可證明公開技術合同中存在三種 order list，但不能推導個人帳戶的圖形介面、地區入口或支援交易對。讀者應把公開文件當作名詞與狀態的核驗基準，把自己帳戶的可用性視為另一個需要當日確認的問題。若任一條件不清楚，正確動作是暫停，不是照著舊影片猜按鈕。

order list 是管理關係，不等於每張訂單同時都在訂單簿工作。working leg 指已按規則進入目前工作階段的那一腿；pending leg 指仍等待前置事件、尚未轉成正常工作訂單的那一腿。官方 ENUM 文件把 PENDING_NEW 描述為訂單列表中、需等 working order 完全成交才離開等待階段的狀態。這個定義非常重要：畫面或回應中看見一筆 pending 記錄，不代表它已在市場提供流動性，也不代表它的價格保護已經生效。

讀取關聯訂單時至少要保存五個層次：list 本身的識別碼、每一腿的 orderId 或 clientOrderId、每腿的 side 與 type、每腿的即時 status，以及觸發或取消的時間。只保存一張最終截圖會丟失過程，尤其在部分成交、網路逾時或重新整理後更危險。對一般使用者，這不表示必須使用 API；它表示要在官方歷史與成交紀錄中逐腿核對，不能只憑「列表消失」判斷整個計畫已成功。

OCO 是 One Cancels the Other。概念上，它把兩個不同條件的訂單放進同一列表；當一腿按規則成交或觸發到需要終止另一腿的狀態時，另一腿被取消。對 SELL 例子，常見教育模型是一腿為高於市場的獲利了結限價，另一腿為低於市場的停止條件；BUY 的價格關係相反。這只是結構示例，實際允許的類型、價格關係與欄位應以當日官方端點和 symbol filters 為準。OCO 不保證取消與成交在使用者視角完全同時，也不保證觸發腿最後按指定價成交。

判讀 OCO 不能只問「哪一腿會先動」，還要問兩腿各自佔用了什麼餘額、是否通過 PRICE_FILTER、LOT_SIZE、NOTIONAL 或其他過濾器，以及一腿部分成交時列表如何回報。若一腿已部分成交，剩餘數量、另一腿取消狀態與可用餘額可能需要分開核對。使用者應把 CANCELED、FILLED、PARTIALLY_FILLED、REJECTED、EXPIRED 視為不同結果，不應把所有非 NEW 狀態都簡化成「完成」。真正的完成證據是成交明細、取消明細、剩餘餘額和列表狀態彼此一致。

OTO 是 One Triggers the Other。它有一個 working leg 與一個 pending leg；pending leg 要等 working leg 完全成交後才被放到正常工作流程。這與 OCO 的兩腿互斥模型不同：OTO 的核心不是「二選一」，而是「先完成 A，再建立或啟動 B」。若第一腿只部分成交，不能自行假設第二腿已經按部分數量工作；應查看官方回應與歷史狀態。若第一腿被取消、拒絕或到期，第二腿是否仍維持 pending、被取消或未建立，也必須以實際紀錄判斷。

OTO 的主要風險是時間間隔與狀態錯覺。第一腿完成到第二腿可見之間可能存在處理與畫面更新差異；在急速行情中，第二腿即使成功建立，也可能因價格已移動而長時間未成交。使用者不能把「觸發第二腿」寫成「以指定結果退出」。若第二腿為限價，它仍受訂單簿與流動性約束；若其參數在觸發時不再符合過濾器或帳戶條件，應準備處理拒單或未知狀態。計畫要先寫回退方法：查列表、查兩腿、查成交、查餘額，再決定是否需要人工處理。

OTOCO 可理解為 One Triggers One Cancels the Other。開始時有一個 working leg，另有兩個屬於後續 OCO 的 pending legs；當前置 working leg 完全成交，後續兩腿才形成可工作的 OCO 關係。它比 OTO 多一個後續分支，也比單純 OCO 多一個前置條件，因此至少要追蹤三張訂單和一個列表。官方 Filters 文件還說明 OTOCO 在 MAX_NUM_ORDER_LISTS 計算中算一個 order list，但建立時仍會影響未成交訂單計數；讀者不能只看列表數就忽略每張訂單對其他上限的影響。

最常見誤解是把 OTOCO 當成「進場後自動安排停利停損結果」。實際上，前置腿可能未成交或只部分成交；後續兩腿可能尚未工作；其中一腿觸發不等於在指定價格成交；取消另一腿也可能在使用者重新整理前後呈現不同時間。若後續 OCO 中的一腿是 stop-limit，觸發只會使限價單開始工作，遇到跳空可能沒有成交。OTOCO 提供的是關係自動化，不能決定最後結果。任何教學若省略 pending leg、部分成交和觸發後未成交，就沒有描述完整風險。

關聯結構正確仍可能因 symbol filters 被拒絕。PRICE_FILTER 檢查 price 或 stopPrice 的最小值、最大值與 tickSize；LOT_SIZE 檢查 quantity 的 minQty、maxQty 與 stepSize；MIN_NOTIONAL 或 NOTIONAL 檢查價格乘數量的名目範圍；MAX_NUM_ORDERS、MAX_NUM_ALGO_ORDERS、MAX_NUM_ORDER_LISTS 則限制未成交訂單或列表數。這些值可能按交易對改變，不能從文章複製。若三腿中任一腿使用不合規的精度或名目，整個列表可能無法如預期建立。

實務核對時，應把每腿輸入保留原始值，再另外計算符合 tickSize 與 stepSize 的候選值；不要先四捨五入後就忘記原意。對 OCO，要檢查兩腿的價格關係；對 OTO，要檢查第一腿成交後第二腿仍可能面對的過濾器；對 OTOCO，要對三腿分別驗證，再檢查 order list 上限。若官方介面已替使用者限制欄位，仍不能假設所有經濟風險已被驗證。介面能阻止格式錯誤，不能判斷這個關聯計畫是否適合個人。

部分成交會讓簡單的二元流程失效。假設 working leg 原數量為 10 單位，先成交 4 單位，剩餘 6 單位仍在等待；此時使用者若看到餘額變動就手動建立另一筆 10 單位訂單，可能造成重複曝險。正確做法是先查 executedQty、origQty、列表狀態與後續腿狀態。取消請求也可能與成交同時接近撮合引擎，不能只因按下取消就假設剩餘量為零。最後必須以取消回報、成交回報和餘額三方一致為準。

網路逾時更容易引發重送。若提交 OTOCO 後沒有立即收到成功畫面，重按可能建立第二個列表；若使用相同 client id，可能被拒絕，也可能因前一筆狀態不同而產生混淆。官方文件對逾時的核心提醒是：逾時不代表撮合引擎沒有處理。一般使用者應先搜尋 open orders 與 order history；程式整合者則需使用唯一識別碼、查詢端點與冪等策略。無論哪一種，都不應把「沒有看到成功提示」直接等同「沒有訂單」。

第一類是輸入錯誤，例如價格精度、數量步進、名目金額或價格關係不符合規則；應回到 exchangeInfo 與 filters，而不是反覆改最後一位數。第二類是餘額或未成交上限問題；應核對 locked balance、open orders 與 MAX_NUM_ORDER_LISTS。第三類是時間戳、簽名、權限或網路問題；使用者不應把 API 金鑰交給第三方代查。第四類是產品或地區不可用；正確答案是停止並依帳戶內官方通知處理，不使用 VPN、虛假資料或他人身分，並遵守 KYC 規則。

回退紀錄最好包含：錯誤碼與完整訊息、交易對、列表類型、每腿不含敏感資訊的參數摘要、本地時間與伺服器時間差、是否已查 open order、是否有任何部分成交、最後可用餘額。不要公開 API key、secret、signature、OTP、裝置識別資訊或完整帳戶截圖。若向官方支援求助，只提供其安全表單要求的最少資料。看不懂錯誤時，保留原始訊息比自行翻譯成「系統壞了」更有用。

OCO、OTO、OTOCO 會減少某些手動步驟，但不應讓使用者放棄裝置安全、2FA、防釣魚碼、登入裝置檢查與提款白名單。若使用 API，權限應最小化，不開啟不需要的提款權限，限制可用 IP，並定期撤銷不用的金鑰。本文不要求建立 API；公開 API 文件在這裡主要用來核驗產品狀態語義。任何網站若要求輸入 secret key、OTP 或助記詞來「測試 OCO」，都應立即關閉。

也要防範假支援人員利用 pending leg 製造緊迫感。真正的狀態只能從自己的官方帳戶、官方 App 或官方文件確認。不要安裝遠端控制軟體，不要分享螢幕中的餘額、QR code 或驗證碼。若看到與本文不同的新功能名稱，先查官方 change log；不要因名稱相似就假設 OPO、OPOCO、OCO、OTOCO 的關係完全相同。產品演進越快，越需要以當日文件重新建立名詞表。

產品文件改版時，不需要憑記憶重做所有測試，但至少要重新核對交易端點中的列表名稱、每腿允許的訂單類型、觸發條件、取消行為、逾時語義、錯誤碼，以及 Filters 頁面的 PRICE_FILTER、LOT_SIZE、NOTIONAL、TRAILING_DELTA 與 MAX_NUM_ORDER_LISTS。若 change log 出現新的列表類型，也不能因名稱相近便套用既有 OCO 或 OTOCO 流程。應先建立獨立術語表與測試案例，確認舊欄位是否仍有相同含義。文章日期只能表示本次核驗時間，不代表頁面永久有效；每次實際操作前仍以官方現行文件與帳戶顯示為準。

複核結果應留下來源網址、存取日期、變更摘要與受影響段落。若只是畫面翻譯改名但狀態語義未變，可以更新詞彙對照；若觸發、計數或取消規則改變，就應暫停依賴舊流程，重跑小額演練與故障回復檢查。對一般讀者而言，最安全的判斷信號是：文件與介面無法互相印證時先不下單，客服回覆無法對應自己帳戶紀錄時先不增加曝險，任何人要求提供金鑰或 OTP 來代為查錯時立即停止聯絡。