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。设计能降低漏单的概率、缩小影响范围，但没办法把可能性归零。任何人 如果拿自己的平台讲出相反的话，那句话背后大概是没有东西可以佐证的。

常见问题