Spot 追蹤止損：追蹤距離、觸發價格與失敗邊界

追蹤止損的核心只有一條規則：系統持續記錄進場後對你有利的那個極值，並在極值的反方向留出一段距離；一旦價格從極值回撤超過這段距離，訂單就被觸發。距離可以用百分比表示，也可以用絕對價差表示，兩者的差別在於價格走遠之後，百分比距離會跟著放大，絕對價差則維持不變。以做多為例，若進場後最高價來到 100、回撤比例設 3%，觸發價就是 97；價格續漲到 120 時，觸發價自動抬到 116.4，但價格回落時觸發價只會停在原地、絕不下移。這種「只朝有利方向移動、從不回頭」的棘輪特性，就是追蹤止損與固定止損最根本的差別。

同一條規則也解釋了它最常見的失效方式。回撤比例設得太窄，日內正常的震盪幅度就足以打到觸發價：趨勢根本沒有反轉，倉位卻先被雜訊掃出場，接著只能看著價格沿原方向繼續走。設得太寬，則等到觸發時已經把大半浮盈還了回去，保護效果接近於無。比較穩妥的做法，是先量出標的近期的日常波動幅度，把回撤距離放在明顯大於雜訊、又明顯小於你願意承受的最大回吐之間，而不是套用一個聽起來安全的整數。還要記住一件事：觸發只是把一張市價或限價單送出去，觸發價不等於成交價；在跳空或流動性稀薄的時刻，兩者可以差得很遠。以下各節就把這些通用原則，對應到公開文件裡的具體參數、換算單位與過濾器限制上。

Trailing Stop 在啟動後追蹤市場向有利方向形成的極值，再以 trailingDelta 定義容許的反向移動距離。它不是把成交價固定在某個百分比，也不是每次價格更新都移動一張可見限價單。當反向變動達到指定距離時，條件才觸發；觸發之後仍要經過訂單規則與撮合。若後續類型含限價，市場跳過該價格時可能保持未成交；若可成交數量不足，也可能只有部分成交。因此「已追蹤」「已觸發」「已成交」必須分成三個事件保存。

方向判讀同樣重要。官方 FAQ 以買賣方向及 stop-loss、take-profit 變體說明何者追蹤最低價、何者追蹤最高價，以及觸發需要向上或向下移動。讀者不應背一個通用箭頭套在所有情況，而要先寫 side、order type、開始追蹤條件和反向 delta，再用官方表格逐項核對。只要其中一項無法說清楚，就先停止，不用小數位試錯來猜系統行為。

Spot 文件用 trailingDelta 表示追蹤距離，單位是 BIPS，也就是基點。1 BIP 等於 0.01%，100 BIPS 等於 1%。例如純粹為了計算演練，若 tracking delta 是 250 BIPS，比例就是 2.5%；這只解釋單位，不表示 2.5% 適合任何資產、週期或帳戶。計算表應同時保留原始 BIPS、換算比例與公式，避免把 250 誤寫成 250%，也避免介面以百分比顯示時反向換算出錯。

BIPS 並非任意整數。交易對的 TRAILING_DELTA 過濾器會依買賣方向和訂單類型提供不同的 minTrailingAboveDelta、maxTrailingAboveDelta、minTrailingBelowDelta、maxTrailingBelowDelta。提交前要以當下 exchange information 核對所屬區間；文章中的歷史值不能代替即時查詢。若參數超出區間，正確處理是重新確認意圖與規則，而不是反覆增加或減少數字直到系統接受。

官方 FAQ 說明 stopPrice 可以與 trailingDelta 一起使用，也可以省略。若提供 stopPrice，價格先要符合該啟動條件，系統才從之後的交易開始追蹤；啟動前出現的更高或更低價格通常不計入後續極值。若不提供，文件描述為從下一筆交易開始追蹤。這兩種設計會產生不同時間軸，測試紀錄必須標明 stopPrice 是否存在，而不能只記最後 delta。

stopPrice 本身還要符合 PRICE_FILTER 等交易對規則。即使它格式正確，也只控制何時開始追蹤，不指定最後成交價。若啟動後市場先向有利方向延伸，追蹤基準會隨新極值更新；直到價格從該極值反向移動達到 trailingDelta，才進入觸發。把 stopPrice 當成成交承諾，會在跳空或薄流動性時高估控制力。

Trailing Stop 自動化的是觸發條件，不是市場深度。觸發時若買賣盤變薄、價格跳空或波動擴大，實際成交可能偏離觸發參考；限價版本還可能因價格未回到限價而停留。訂單也可能受 LOT_SIZE、NOTIONAL、可用餘額、最大未成交訂單數或其他 filters 影響。先前驗證通過不代表觸發時所有帳戶條件仍未變，因此要為拒單或未成交設計停止流程。

部分成交不能歸類為成功或失敗二選一。應記 executed quantity、remaining quantity、平均成交價、費用、仍開啟數量與可用餘額，再決定是否人工處理。不要因為追蹤條件已觸發，就假設完整數量已離開風險部位；也不要在未查明剩餘訂單前另建相同數量。最終核對至少包含 order history、trade history、open orders 與資產餘額。

第一組檢查是語義：side 是否正確、訂單類型是否支援 trailingDelta、是否需要 stopPrice、應追蹤最高還是最低極值、反向方向為何。第二組是數值：BIPS 換算是否正確、是否落在 TRAILING_DELTA 對應區間、price 與 stopPrice 是否符合 tickSize、quantity 是否符合 stepSize、名目是否達門檻。第三組是帳戶：可用而非總餘額是否足夠、是否已有鎖定資產、未成交訂單上限是否接近。

第四組是故障邊界：逾時後如何查詢、拒單時保存哪些欄位、部分成交如何停下、誰有權取消、監控中斷時是否禁止自動補單。若使用程式整合，還要校準伺服器時間、使用唯一 client order id、限制 API 權限與來源 IP，並把 secret 排除於日誌。一般讀者不需要建立 API；公開 API 文件在本文只是用來核對產品規則。

若出現 filter failure，回到交易對規則判斷是 TRAILING_DELTA、價格、數量還是名目問題；若是餘額或訂單上限，核對鎖定資產與 open orders；若是時間戳、簽名或權限錯誤，停止程式並保護憑證；若產品或地區不可用，接受限制而不繞過。錯誤訊息、時間、交易對、非敏感參數摘要與訂單識別碼應原樣保存，不能只記「下單失敗」。

停止條件至少包含：無法確認方向與追蹤極值、BIPS 不符合 filter、文件與介面語義衝突、帳戶資格不明、回應逾時且查詢仍未知、已有無法解釋的 open order、餘額對不上、或任何人要求分享 OTP、API secret、簽章。停止不是失敗；它是避免第二個動作掩蓋第一個未知狀態的控制措施。

Trailing Stop 會降低持續手動調整條件的需求，但不能取代 2FA、反釣魚碼、裝置檢查、提領白名單與最小 API 權限。不要把 secret、OTP、完整 QR code 或帳戶截圖交給聲稱能代設參數的人。若使用 API，只開啟確實需要的交易權限，限制 IP，禁止提領權限，定期撤銷不用的金鑰，並讓日誌遮罩簽章與敏感標頭。

監控訊息應區分「開始追蹤」「刷新極值」「已觸發」「部分成交」「完全成交」「拒絕」「取消」與「查詢未知」。只推送一條「止損成功」會隱藏尚未成交的風險。警報失聯時應進入人工核對與禁止補單狀態，而不是持續嘗試；恢復後先重建訂單、成交、餘額三者的一致快照。

操作後依序核對：一、訂單識別碼與原始參數；二、是否已開始追蹤；三、目前追蹤的是最高或最低極值；四、觸發事件與時間；五、後續訂單狀態；六、成交數量、價格與費用；七、open orders、鎖定餘額與可用餘額。若取消，還要確認取消與成交是否在接近時間競爭，不能只看按鈕已變灰。

文件或產品更新後，重新檢查 trailingDelta 單位、stopPrice 選擇、方向表、TRAILING_DELTA 範圍、支援類型、錯誤碼與帳戶可用性。保存來源網址、查閱日期和變更摘要。本文的 2026-08-09 日期只代表本輪查核，不會凍結平台規則；任何無法由當日官方資料與自己帳戶互相印證的欄位，都應回到停止狀態。