晚上八点跑脚本的行情里，最容易出现的一种事故是：人的网络断了，单还在交易所里活着。断线本身不会撤销任何东西——订单存放在撮合系统一侧，和你的连接状态无关——真正决定后果的是断线前后那几分钟里订单被行情扫过的程度。本文按平台机制与自建防线两层拆一遍，机制说明撰写于 2026 年 9 月，各平台参数名称与行为以官方文档为准。
先纠正一个常见误解：『我断线了所以单没了』和『我断线了所以单安全』都不对。断线后挂单继续排队，行情剧烈时可能按你几周前设的价格成交；也可能你挂的是永不过期的限价单，断线一周后它还在同一档位等着。订单在断线期间的存续规则，取决于下单时选的有效期类型和平台对长期闲置挂单的处理，这两项都写在订单规则文档里，而不是断线提示弹窗里。
平台侧第一道防线是会话与心跳机制。通过 API 或 WebSocket 接入时，连接需要周期性维持，超过平台规定的时限没有心跳，会话会被判定失效；部分平台在会话层提供连接断开即撤单类的参数或开关，用于让程序化订单在连接死亡后不留在簿上。这类参数是不是存在、作用于全部订单还是单个订单、断线多久触发，各家定义不同，使用前查官方接口文档，不要从别的平台的经验倒推。
第二道防线是会话恢复规则。重连时系统要么把你的会话接续回去，要么把旧会话挤下线。对个人用户，这体现为『账号在另一台设备登录』的提示；对 API，表现为旧密钥的会话失效。若你在两处同时跑同一策略而平台不做会话互斥，两边的挂单会同时留在簿上，等于仓位翻倍——这是双设备办公人群最常见的重复下单原因之一。
第三层才是用户自建看门狗：一个独立进程定时检查交易连接与账户挂单状态，超时未刷新就调用撤单接口。它的可靠性上限取决于看门狗自己活着的概率：主脚本假死时看门狗可能一起卡住；网络抖动可能造成误撤单，你本来想留的趋势单被全部清空；两台机器各跑一套看门狗还会互相撤对方的单。用它之前先想清楚误动作的代价，再给它配只保留交易权限、关闭提币权限的最小化密钥。
低技术的备份往往更有效：手机移动网络作为第二通道装一个官方 App，断线后先用手机看真实挂单状态而不是重跑脚本；提币白名单提前设好，把断线事故的上限锁在成交偏差而不是资产转走。极端行情中平台的撮合与推送链路本身可能降级，那时断线提示未必是问题根源，把状态页与故障公告纳入同一轮判断。
自查清单：重新登录后第一件事是核对挂单列表而不是成交记录；检查有没有有效期为永久且早已失去价格参照的僵尸单；给常驻策略的挂单统一带上到期时间，宁可每天重挂也不要留过夜裸单；确认双设备场景下平台的会话互斥行为，避免两边同时挂单。\n\n还有一条时间维度的纪律值得单列：断线事故的复盘要留书面记录。每次掉线后记下起止时间、当时的挂单状态、恢复后发现的成交明细，积累几轮之后你会发现规律——掉线高发在哪个网络环境、哪个时段、哪类行情，防线该加在本地网络、密钥权限还是挂单有效期上，数据比猜测可靠。没有记录的习惯，同样的事故会每隔几周重演一次，而每次的成本都不相同。另外注意一个容易被忽略的边界：断线撤单类机制防的是连接死亡，防不了逻辑死亡——程序活着但判断出错时，所有订单在平台看来都合法，心跳一切正常，这类事故的兜底只能是仓位上限与风控告警，而不是任何断线开关。加密资产交易存在价格波动与执行偏差风险，本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。