如何检查币安现货订单是否部分成交

了解订单状态字段

1. 币安订单响应中的状态字段指示当前生命周期阶段： NEW 、 PARTIALLY_FILLED 、 FILLED 、 CANCELED或REJECTED 。

2. PARTALLY_FILLED值表示至少发生了一次填充，但完整的origQty仍未执行。

3. 无论是否需要进一步填充，该状态都会在第一次部分执行后立即返回。

4. 一直持续到剩余数量全部执行或订单被手动取消。

5. 状态更新通过get_order上的 REST 响应传递，并通过用户数据流事件实时传输。

分析执行数量

1. 将executedQty与origQty进行比较：如果executedQty大于零但小于origQty ，则订单已部分成交。

2. 检查cummulativeQuoteQty — 它反映了迄今为止匹配的总报价资产价值，并且在存在部分填充时必须非零。

3. 检查fills数组：非空列表确认至少发生了一笔交易执行。

4. fills中的每个条目都包含价格、数量、佣金和tradeId ，提供部分执行的详细证据。

5.注意executedQty和cummulativeQuoteQty是字符串类型的十进制值；必须避免直接浮点比较，以防止精度损失。

使用 get_order API 端点

1. 使用有效凭证和正确的符号大小写调用trade.get_order(symbol='BTCUSDT', orderId=123456789) 。

2. 解析响应中的数据对象——不要仅仅依赖于顶级代码或消息字段。

3. 从嵌套数据有效负载中提取status 、 executedQty 、 origQty和fills 。

4. 验证数字一致性：确保executedQty ≤ origQty且cummulativeQuoteQty与所有成交的price × qty之和相匹配。

5. 将任何与此不变量的偏差视为需要手动协调或上游调查的异常。

通过用户数据流进行监控

1. 在有效的用户数据流WebSocket连接下订阅executionReport事件。

2. 过滤eventType等于executionReport且symbol与目标交易对匹配的消息。

3. 通过检查executionType是否等于TRADE ，同时orderStatus仍为PARTIALLY_FILLED来检测部分成交。

4. 从每个执行报告中累积lastExecutedQuantity和lastPrice以重建填充历史记录而无需轮询。

5. 使用eventTime按时间顺序对填充进行排序，并识别由网络抖动或重新连接引起的间隙或重复报告。

常见问题解答

问：PARTIALLY_FILLED 状态被举报后可以恢复为 NEW 吗？答：不会。币安的订单状态机是严格单调的。一旦发出PARTALLY_FILLED ，它只会转换为FILLED 、 CANCELED或EXPIRED 。

问：get_orders_pending 是否包含部分成交的订单？答：是的。 get_orders_pending返回所有未结订单，包括状态为PARTALLY_FILLED和剩余未成交数量的订单。

问：成交发生和 get_order 中出现的状态更新之间是否存在延迟？答：正常情况下，REST API会在100毫秒内反映最新状态。在交换维护窗口或区域 API 路由故障期间可能会出现较高的延迟。

问：订单部分执行后被取消时，填充数组会发生什么情况？答：填充数组保持完整且未更改。取消仅影响未来的执行；历史填充是不可变的并保存在订单记录中。