TradingView 或交易所當機時，你的自動化策略會發生什麼事？
備援設計怎麼做

「交易所總有斷線保護吧？」有，但不一定輪得到你。Bybit 的斷線自動撤單（官方名稱 Disconnect Cancel All）文件裡寫得很直白：僅限機構客戶，連 VIP 客戶都不能用。 也就是說，如果你是在 Bybit 上跑自動化策略的散戶，這道你以為存在的安全網，根本開不了。

這篇處理的就是這類落差：上游出事的那一刻，哪些保護是真的存在，哪些只存在於你的想像。 先講結論——你開的部位不會因為斷線而消失，但你的停損有可能形同不存在。

你的停損放在哪裡，決定了斷線那一刻會發生什麼事

停損有兩種放法，看起來都叫停損，斷線時的命運卻完全相反。這是全篇最該先搞清楚的一件事。

這也是為什麼 TVSBot 對期貨部位是把停利／停損直接下成掛在交易所上的綁定單（bracket order），而不是只靠軟體邏輯追蹤一個價位——掛在交易所的單子撐得過你斷線，沒送出去的邏輯不會。

交易所的斷線自動撤單，不是人人有份

所謂斷線自動撤單（dead man's switch），是你持續呼叫一個端點當心跳， 心跳停止超過設定的倒數秒數，交易所就自動撤銷你掛著的訂單。四家的資格條件差很多。

Bitget 把維護時段寫進 API 文件了，其他家沒有

每家交易所都會排計畫性維護，差別在於官方願意把「什麼時候」講到多清楚。以下三家有明確說法：

Binance 這邊我們查不到 binance.com（全球站）獨立的公開事故／狀態頁，只找到一個回傳 normal 或 maintenance 的 GET /sapi/v1/system/status 端點。對照之下，Bitget 是唯一讓你 在寫程式當下就知道「每週二、三、四下午別排重要動作」的，而不是上線後撞到錯誤碼才發現。

TradingView 那邊，官方只承認到哪裡

TradingView 有官方 status page：status.tradingview.com，其中有獨立的 「Alerts」項目。查證當下顯示 Operational，近期與 alert 相關的事件只有一筆：「Technical alerts partly unavailable」（Jul 1, 10:14 至 Jul 3, 18:23 GMT，已標記解決）。故障會發生，官方也有公開記錄——但從未說明，故障期間該觸發卻沒觸發的 alert，服務恢復後會不會補送。

這裡要講精確一點，因為有一套廣為人知的 webhook 重送機制常被誤以為涵蓋這種情境。它只適用於你自己的接收端伺服器出錯：回 5xx（官方原文把 504 排除在外） 會在 5 秒後重送、最多 3 次；回 504、回 4xx 或 3 秒內沒回應，一律不重試，直接視為已送達 並丟棄。TradingView 自己服務降級是另一回事。接收端的完整拆解看webhook 延遲那篇；alert 完全沒觸發的話，這份除錯清單先排查更常見的原因。

我們沒辦法逐字引用的那句話

沒有任何一家交易所白紙黑字寫過「你斷線時部位不會被關掉」。這個結論是我們自己綜合出來的： 每一份斷線自動撤單文件都把範圍限定在掛單，從來沒提過部位；而強平風險由 完全獨立的保證金引擎管理，跟連線狀態無關。這是由好幾份獨立官方文件、用字高度一致所支持的 合理推論——但它終究是推論，不是逐字引用，這個區別我們想講清楚。

上線前先問自己這幾題

答不出來的那幾題，就是你的缺口：

• 我的停損是真的掛在交易所上的一張單，還是只存在策略邏輯裡？
• 我這個帳戶等級，真的用得到這家交易所的斷線自動撤單嗎？——不確定就當作沒有
• 交易所明講「不會公告」的短暫斷線（例如 Bybit 的 10 秒以內），我的程式會自己重連重試嗎？
• 出事之後，我分得出來是「alert 根本沒送到」還是「送到了但後面處理失敗」嗎？ ——只有事前留下訊號紀錄才做得到
• 如果掛掉的剛好是我的 dashboard，我還有第二條管道知道出事、還有辦法手動全平嗎？

誠實的一段：沒有任何設計能保證 100% 不漏單

任何自動化交易架構都保證不了 100% 送達——包括我們自己。TradingView 從未針對自己故障期間 漏掉的 alert 公布任何 SLA；我們也沒有替 TVSBot 公布正常運行時間保證，因為我們自己也沒有 可以拿出來的公開 SLA。設計能降低漏單的機率、縮小影響範圍，但沒辦法把可能性歸零。任何人 如果拿自己的平台講出相反的話，那句話背後大概是沒有東西可以佐證的。

常見問題