7.3 KiB
7.3 KiB
持仓、订单记录、统计与币安一致性说明
在引入「订单号前后一致」处理(entry_order_id / exit_order_id / SYSTEM_ORDER_ID_PREFIX)后,以下内容的状态如下。
一、已能保证的部分
1. 持仓与币安一致
- 仪表板「当前持仓」:数据来自 币安实时持仓(
get_open_positions()),与币安页面一致(仅受POSITION_MIN_NOTIONAL_USDT过滤影响)。 - 补建逻辑:配置了
SYSTEM_ORDER_ID_PREFIX时,仅当能明确查到开仓订单且clientOrderId非空且不以该前缀开头时视为手动单并跳过;其余(含历史单、查不到订单、cid 为空)一律补建并加入监控,避免漏掉系统单。
2. 订单记录与币安可对账
- 开仓:交易系统所有开仓单(非 reduce_only)在配置了
SYSTEM_ORDER_ID_PREFIX时都会带newClientOrderId = 前缀_时间戳_随机(如SYS_xxx),成交后写入 DB 的entry_order_id与client_order_id,与币安一致。 - 成交后落库:开仓成交后
position_manager会调用Trade.create(..., entry_order_id=..., client_order_id=...),订单记录与币安一一对应;若当时落库失败(超时/崩溃),后续同步会通过「补建」把缺失记录补上并纳入监控。 - 平仓:平仓时保存
exit_order_id,Trade.update_exit会做get_by_exit_order_id防重复。 - 同步:
POST /api/account/positions/sync与进程内定时同步:仅当开仓订单clientOrderId明确非系统前缀时跳过补建,其余一律补建(含历史单、未带前缀的单),保证「币安有仓且为系统单」都会被监控。POST /api/trades/sync-binance:用get_by_exit_order_id(order_id)判断是否已同步,避免重复;开仓侧用get_by_entry_order_id(order_id)判断是否已存在。
- 因此:每条 DB 记录都可与币安订单一一对应(通过
entry_order_id/exit_order_id),订单记录与币安在「谁开的、谁平的」上一致。
3. 统计口径与去重
- 统计:来自
Trade.get_all(..., account_id),只统计该账号的 DB 记录。 - 净盈亏:
get_net_pnl(t)逻辑为:- 若有
realized_pnl:用realized_pnl,再若commission_asset == 'USDT'则减去commission; - 否则用
pnl(按价格差算)。
- 若有
- 胜率、总盈亏、盈亏比等均基于上述净盈亏汇总,不会因为重复同步同一条平仓而重复计入(由
exit_order_id唯一性保证)。
二、仍依赖「谁在写」的部分
1. 手续费(commission)
| 场景 | 是否写入 commission | 说明 |
|---|---|---|
| 交易系统内平仓 | ✅ 是 | 从 get_recent_trades 按 exit_order_id 汇总 commission,写入 update_exit。 |
| 仪表板「平仓」按钮 | ✅ 是 | 同上,取成交里的 commission/realizedPnl 写入。 |
| 持仓同步(positions/sync) | ✅ 是(已补全) | 更新 closed 前按 exit_order_id 拉取 get_recent_trades,汇总 commission/realizedPnl 并写入。 |
| 订单同步(trades/sync-binance) | ✅ 是(已补全) | 更新平仓记录前按订单号拉取成交,写入 commission/realized_pnl。 |
因此:所有标记为已平仓的记录都会尽量带上手续费与实际盈亏,统计与币安一致。
2. 实际盈亏(realized_pnl)
- 交易系统平仓、仪表板平仓:从币安成交取
realizedPnl并写入。 - 持仓同步、订单同步:已补全逻辑,同样按
exit_order_id拉取成交并写入realized_pnl。 - 统计中若存在
realized_pnl会优先使用并再扣 USDT 手续费,否则用价格差pnl。
三、小结:能否「直接保证」?
- 持仓与币安一致:可以,当前实现已保证(实时持仓 + 按前缀补建)。
- 订单记录与币安可对账:可以,
entry_order_id/exit_order_id与防重复逻辑已保证一一对应、不重复。 - 统计准确性:在「同一笔平仓只被记录一次」和「按净盈亏汇总」上已保证;手续费与实际盈亏已在所有关仓路径补全:
- 系统/仪表板平仓、持仓同步、订单同步 均会按
exit_order_id拉取成交并写入 commission/realized_pnl,统计与币安对齐。
- 系统/仪表板平仓、持仓同步、订单同步 均会按
四、下单路径与「意外订单」排查
1. 会向币安下单的入口(汇总)
| 类型 | 入口 | 触发条件 | 是否可能「意外」开仓 |
|---|---|---|---|
| 开仓 | trading_system/position_manager.open_position |
仅由策略在「通过风控 + 有信号」后调用;risk_manager.should_trade 会检查:持仓数 ≥ MAX_OPEN_POSITIONS 则 return False,且检查该 symbol 是否已有持仓 |
否。持仓数/已有仓检查均基于币安 get_open_positions(),到上限或已有该 symbol 即跳过,不会下单。 |
| 开仓 | backend/api/routes/account.py 限价下单接口 |
用户在前端/API 主动发起的「手动限价开仓」 | 否,需显式调用。 |
| 平仓 | position_manager.close_position |
仅对 active_positions 中存在的 symbol 调用(止损/止盈/手动);check_stop_loss_take_profit 只遍历 active_positions |
否,只平我们监控的仓。 |
| 平仓 | backend 平仓/一键平仓 | 用户主动平仓 | 否,需显式调用。 |
| 止盈/止损单 | position_manager._ensure_exchange_sltp_orders |
仅在两处调用:(1) 开仓成功后为该 symbol 挂 SL/TP;(2) 补建「仅币安有、DB 无」的持仓时,若开启 SYNC_CREATE_MANUAL_ENTRY_RECORD,为补建记录补挂 SL/TP。挂前会先取消该 symbol 下同类型 Algo 单(STOP_MARKET/TAKE_PROFIT_MARKET),再下新单 | 不会产生「开仓」;可能覆盖用户在该 symbol 上已有的同类型保护单(属预期:补建后统一用系统计算的 SL/TP)。 |
结论:没有逻辑会在「不该开仓」时自动下开仓单;止盈/止损挂单仅对「我们已纳入监控的持仓」补挂或覆盖,不会对「仅币安有、且未补建」的持仓主动挂单(因未进 active_positions 不会走到 _ensure_exchange_sltp_orders)。
2. 日志里「总是想下一些单」是否正常?
- 策略扫描日志(如
处理交易对: SIRENUSDT (UP 31.32%, 市场状态: ranging)、SIRENUSDT 4H趋势中性,信号质量可能降低、SIRENUSDT 持仓数量已达上限:16/16,跳过开仓)
表示:每轮扫描会评估各交易对并可能尝试开仓,但持仓数量已达上限:16/16,跳过开仓时risk_manager.should_trade已 return False,不会调用open_position,也不会向币安下任何单。这是正常、预期行为。 - 挂止盈/止损相关日志(如「已挂币安保护单」「挂止盈单失败」等)
表示:仅对 当前已在active_positions中且具备 SL/TP 价格的持仓 在交易所侧挂或更新保护单;每次挂前会先取消同类型旧单再挂新单,不会重复堆积同一 symbol 的多组 SL/TP。
若希望减少「想下单」类日志的干扰,可将「跳过开仓」类日志级别调低(如改为 debug),或仅在有实际下单时再打 info。