关了 App,交易所的止损单还盯得住了吗:触发逻辑存在哪一侧的差别

很多人对止损单有一个默认假设:只要下单时设好了价格,它就「挂在交易所里」,自己关不关 App 无关紧要。这个假设对一部分订单成立,对另一部分完全不成立。差别取决于触发逻辑运行在哪一侧——交易所的服务器上,还是你自己的设备上。这是订单功能里最少被说明、后果却最直接的分界线。

先说存在服务端的形态。多数主流交易所在条件单、止损单页面上提供的托管触发,由交易所的监控服务持续盯价:条件满足时,系统替你提交一张后续订单。它不看你的 App 是否打开,设备断电、飞行模式、卸载重装都不影响。核验方法是把条件单设在一个很近的价格,然后强制关闭应用甚至换设备登录查看状态——订单仍在列表里,就属于服务端托管。这类订单真正会失效的场景有三类:交易所主动下架该功能或该交易对的条件下单支持;平台维护窗口,监控服务暂停而你的订单还在,价格却继续变化;以及条件单本身设置了到期时间,过期自动作废。第三种常被忽略,设单当天的兴奋过去之后,一周后回来发现单子「安静地消失了」,其实是有效期到了。

再说只在客户端生效的形态。手机上某些「价格提醒加一键卖出」的组合、浏览器页面上的本地脚本、以及网页上部分依赖前端逻辑的自动操作,本质是你的设备在盯价。设备休眠、系统杀掉后台、网络断开,盯价就停了;推送延迟几十秒,提醒才到,价格可能早过了触发位。判断方法很直接:该功能有没有生成一个可以在其他设备上看到的订单记录。看不到,就说明它不存在于服务器,可靠性完全押在你的设备上。

由此可以理解自建策略为什么必须自备运行环境。通过 API 跑的网格、定投或止盈脚本,交易所服务器并不知道它的存在——服务器只看到一笔笔零散的下单请求。自己的笔记本合盖,策略就停了;家用网络抖动,判断条件用的是旧价格。正规做法是把逻辑放在持续在线、时间同步、有重试与告警的服务器上,并且让程序自己维护「我最后一次成功查询是什么时候」的记录。价格提醒和自动执行混在同一套脚本里时,还要防一种连锁故障:网络中断恢复后,脚本用缓存的旧触发条件立刻补发订单,造成与预期完全不同的执行。

服务端形态也不是没有边界,几个细节容易踩坑。触发后的后续订单未必是你预期的类型:有的平台触发后市价,有的可以选限价,而限价在剧烈行情里可能挂空不成交,等于止损没止损。触发价格源的差别(最新成交、标记价格、指数价格)决定了插针时会不会被误触发,各家默认值不同,设单时应主动确认,不要接受默认。条件单与仓位之间通常只有软关联——手动把仓位平掉后,挂在上面的止损条件单不一定自动消失,留下它可能在下一个周期反向触发一张单,清仓之后回列表把残留条件单撤干净是必要动作。

维护窗口的行为值得单独核一次。平台公告里的系统升级,对撮合、监控、风控各组件的影响并不一致;有的公告会写明「条件下单监控暂停」,有的不会。稳妥的做法是:凡是知道有维护窗口的时段,假设自己的条件单不被盯,在窗口前降低杠杆或手动减仓,而不是赌监控服务继续运行。

把上面的差别收成一张自查表:这笔止损在其他设备上看得到吗?触发后提交的是什么订单类型?有没有到期日?维护公告里有没有提到监控?四个问题都能答上来,才可以说这个止损「关着 App 也在工作」。

风险提示:本文仅解释订单执行机制,不构成投资建议,不提供任何止损设置建议。各平台条件单实现与参数差异大且随时调整,请以官方说明与订单实际状态为准;行情剧烈时止损可能无法按预期价格执行。