主账户和子账户的挂单互相冲突时，OKX 的自成交保护（STP）会介入，默认处理方式是取消已经在订单簿上挂着的 maker 订单，让 taker 订单继续与市场上其他人的订单成交。这意味着冲突不会以"自己和自己成交"收场，但被取消的那笔挂单会从订单簿上消失，你需要知道它为什么被撤，以及能不能改规则。
STP 在 OKX 上管的是什么
OKX 对自成交的定义很直接：用户或其子账户不小心匹配到了自己的订单，自己同时成为买家和卖家。从 2024 年 3 月 14 日起，OKX 以主账户维度强制开启 STP，覆盖主账户与自身、同一主账户下子账户之间、以及主账户与所有子账户之间的交易。也就是说，你的主账户挂了一个买单，子账户挂了一个卖单，如果价格交叉，系统会识别为同一主账户体系内的自成交风险并触发 STP，而不是让这两笔单子成交。
触发后的默认行为是取消 maker 订单。假设主账户的买单先在订单簿上（maker），子账户的卖单后来（taker）且价格能匹配，那么主账户的买单会被撤掉，子账户的卖单继续往下吃其他人的买单。反过来，如果子账户的挂单是 maker，主账户的新订单是 taker，被撤的就是子账户那笔挂单。
想改 STP 模式，只有 API 用户能做
网页端和 App 端用户没有切换 STP 模式的入口。OKX 官方说明中，只有 API 用户可以通过 stpMode 参数为新订单指定部分订单类型的 STP 模式。API 文档和社区提交记录显示，OKX 支持的 stpMode 取值包括 cancel_maker、cancel_taker、cancel_both，分别对应撤挂单、撤吃单、两边都撤。如果你不使用 API 下单，STP 对你来说就是强制开启且固定为撤 maker 的模式，无法在界面上修改。
这带来一个实际后果：如果你用主账户和子账户分别跑策略，而两边不小心在相近价位挂出了方向相反的单子，STP 撤掉的那笔挂单可能正是你某个策略的组成部分。被撤的订单不会成交，但策略本身可能还在运行，后续可能再次挂出类似订单、再次被撤，形成反复。这不是 STP 故障，而是策略设计没有考虑同一主账户体系内的订单隔离。
怎么查是不是被 STP 撤了
网页端和 App 端可以在订单历史中查看订单是否因为自成交保护而被撤。API 用户可以通过查询订单历史的 REST 接口，或订阅订单 WebSocket 频道获取撤单信息。看到一笔订单状态变为"已撤销"且你并没有手动操作时，结合同一时间段内主账户或子账户是否有反向订单在相近价格出现，基本可以判断是 STP 触发。不要把它当成系统故障去反复提交工单，先检查同一主账户体系下的订单分布。
更实际的规避方式
如果你的交易方式不需要主账户和子账户之间产生价格交叉的挂单，STP 不会主动干扰你。真正需要留意的是多策略并行的情况：同一币种、相近价格、方向相反，分属不同子账户或主/子账户，就容易触发。处理方式不是关掉 STP（也关不掉），而是从订单布局上错开。比如让不同子账户负责不同币种或不同价格区间，避免在同一个订单簿位置出现来自同一主账户体系的对手方挂单。
对于必须使用 API 且需要特定 STP 行为的用户，可以在下单请求中传入 stpMode。但要注意 cancel_both 在 FOK 订单等组合下可能被拒绝，CCXT 的提交记录显示 OKX 对部分参数组合会返回错误。如果你不熟悉 API 参数之间的交互，保持默认的 cancel_maker 并用订单布局来规避冲突，比改一个可能引发新报错的参数更稳妥。
