订单跟踪系统严重 Bug 分析报告（第二期）

分析日期：2026-02-20
涉及版本：当前 main 分支

核心根因

所有严重 Bug 源于同一设计缺陷：

orderUpdates WS 消息仅含挂单价 limitPx，真实成交价在 userFills 消息中。但当前代码在 orderUpdates 到达时就删除追踪记录并唤醒等待线程，导致 userFills 的价格修正永远失效。

核心涉及文件：

• src/trading/websocket_order_manager.py — 订单追踪核心
• src/trading/executor.py — 下单与追踪流程
• src/trading/position_manager.py — 仓位生命周期
• src/trading/trade_repository.py — 数据持久化
• src/utils/database/timescaledb.py — 数据库层

Bug 清单

🔴 Bug 1 — 成交价/成交量字段取错，导致价格数据系统性错误

文件: src/trading/websocket_order_manager.py:142-145

# _on_order_update 收到 "filled" 消息时
tracking.avg_price = float(order.get("limitPx", 0))   # ← 错误！limitPx 是挂单价，非成交价
tracking.filled_size = float(order.get("origSz", 0))  # ← 错误！origSz 是原始委托量，非实际成交量

问题本质：

• limitPx = 下单时设定的限价（挂单价格），对 Taker 成交而言可能与实际成交价不同
• origSz = 委托总量，部分成交场景下实际成交量远小于 origSz

影响：

• position_manager._calculate_realized_pnl 使用的 order_result.leg_a.price 是 limitPx，不是真实 avgPx
• trade_orders 表中记录的 price 字段同样错误
• PnL 计算偏差，尤其对 Taker 成交（市场快速移动时影响最大）

现有缓解措施：executor._backfill_order_price() 在 fill 后通过 HTTP 额外查询修正，但见 Bug 4。

🔴 Bug 2 — userFills 价格修正机制失效（竞态条件）

文件: src/trading/websocket_order_manager.py:159-161 vs 163-190

问题描述：_on_order_update 在调用 result_event.set() 之后立即删除追踪记录：

tracking.result_event.set()
with self._lock:
    self._tracking.pop(oid, None)   # ← 此刻追踪记录消失

随后到达的 userFills（含真实成交价 px 和 sz）在 _on_user_fill 中：

with self._lock:
    tracking = self._tracking.get(oid)   # ← 返回 None（已被删除）
if not tracking:
    continue   # ← 正确价格被完全丢弃！

两种时序均有问题：

结论：_on_user_fill 设计为提供真实成交价的功能，在所有场景下均无法生效。

🔴 Bug 3 — 无锁并发写入 tracking 字段（数据竞争）

文件: src/trading/websocket_order_manager.py:136-161, 181-190

_on_order_update 和 _on_user_fill 均在释放 _lock 后修改 tracking 的字段：

with self._lock:
    tracking = self._tracking.get(oid)
if not tracking:
    continue
# ← 锁已释放！

# 以下写操作无保护：
tracking.status = OrderStatus.FILLED         # WebSocket 线程写
tracking.avg_price = float(order.get(...))   # WebSocket 线程写
# 同时 _timeout_then_verify 线程可能在写：
tracking.avg_price = ...                     # 超时监控线程写（via _resolve_via_http）

同样问题存在于 _on_user_fill:188-190 的 avg_price 和 filled_size 写操作。

潜在后果：多线程同时修改价格字段，CPython GIL 仅保证单条字节码原子性，不保证操作顺序和可见性。在高频场景下可能产生脏读/脏写。

🔴 Bug 4 — _backfill_order_price 总是额外 HTTP 调用（性能+可靠性）

文件: src/trading/executor.py:589-595

if tracking.status == OrderStatus.FILLED:
    ...
    # 回填真实成交均价（WS 可能只有 limitPx，HTTP 有 avgPx）
    self._backfill_order_price(order_result, coin)  # ← 每次 fill 都额外 HTTP 调用

_backfill_order_price 对每个成交的限价单发起 HTTP API 调用 query_order_by_oid。

问题：

• 每次成交增加 50-200ms 延迟（在高波动市场中代价较高）
• HTTP 调用可能失败（网络抖动、API 限速）。失败时仅记录 warning，使用错误的 limitPx 继续执行
• 失败后 order_result.price 仍为错误的 limitPx，PnL 计算错误

# executor._backfill_order_price
except Exception as e:
    logger.warning(
        f"回填成交价异常（使用限价）: {coin} oid={order_result.order_id} | {e}"
    )
    # ← 静默失败，price 保持 limitPx

🟡 Bug 5 — 超时监控线程大量堆积（资源浪费）

文件: src/trading/websocket_order_manager.py:63-65

threading.Thread(
    target=self._timeout_then_verify, args=(oid,), daemon=True
).start()

每个被追踪的订单创建一个守护线程，线程 time.sleep(timeout_seconds)（默认 600 秒）。

问题：

• 即使订单在 1 秒内成交，线程仍休眠近 10 分钟才退出
• 高频下单时可能存在数百个空闲线程同时存在
• 缺少线程数量上限，理论上无限增长

现有保护：线程是 daemon=True，进程退出时自动清理；超时后检查 if oid not in self._tracking: return 避免重复处理。但资源浪费仍存在。

🟡 Bug 6 — 平仓 DB 更新失败后状态不一致（重启后双重平仓风险）

文件: src/trading/position_manager.py:527-548 vs src/trading/trade_repository.py:198-203

平仓成功后执行流程：

# 内存操作（已执行）
position.status = PositionStatus.CLOSED
self._positions.pop(key, None)          # ← 内存中已删除

# DB 操作（可能失败，但异常被静默吞噬）
self._repo.update_position_status(...)  # 失败时：捕获 psycopg.Error，仅 logger.error
self._repo.save_order(...)

若 update_position_status 因 DB 故障失败：

• 内存：仓位已关闭（_positions 中已删除）
• DB：仓位状态仍为 CLOSING（更新失败）

重启后：get_open_positions 查询 status IN ('open', 'opening', 'closing') 会返回此仓位，recover_positions_from_db 重新加载：

• 若交易所已无此仓位 → 作为幽灵仓位关闭（无损）
• 若交易所仍有持仓 → 再次尝试平仓，可能导致超量平仓或 DB 重复订单记录

🟡 Bug 7 — Leg B 平仓失败时 base PnL 丢失（统计失真）

文件: src/trading/position_manager.py:694-701

else:
    # Leg B 失败：用 mid_price 估算（仍有残留仓位，PnL 应计入）
    base_exit_price = self._executor.get_all_mids().get(symbol_to_coin(position.base_symbol), 0.0)
    if base_exit_price > 0:
        logger.warning(f"⚠️ Leg B 平仓失败，使用 mid_price 估算 base PnL: ...")

如果 base_exit_price = 0（mid_price 也不可用），则 base_pnl = 0.0。

问题：

• Leg B 仓位仍在交易所上，但系统按 base_pnl=0 记录到 DB
• daily_trading_stats 中的 total_realized_pnl 不含 base 腿的真实盈亏
• 系统认为该仓位已关闭，但实际 Leg B 转为孤儿仓位管理（_adopt_residual_base_leg），孤儿仓位平仓后的 PnL 不会合并回原仓位统计

🟢 Bug 8 — save_signal 异常静默吞噬（无监控告警）

文件: src/trading/trade_repository.py:91-92

except psycopg.Error as e:
    logger.error(f"保存交易信号失败: {signal.signal_id} | {e}", exc_info=True)
    # ← 异常被吞噬，无 Lark 告警推送

信号是整个交易链路的入口记录。信号丢失时缺乏告警通知，运营侧难以发现。其他关键操作（如开仓失败、平仓失败）均有 sender_colourful 告警，此处缺失。

🟢 Bug 9 — 数据库连接预验证无效

文件: src/utils/database/timescaledb.py:199

conn.isolation_level  # 触发异常如果连接无效

在 psycopg 3.x 中，isolation_level 是连接对象的本地属性（非数据库往返查询），对已断开的连接不会抛出异常。注释意图是"验证连接健康"，但实际上此检查无效，失效连接仍会被 yield 出去，到实际 SQL 执行时才报错。

严重性总览

建议修复方向

Bug 1-4（同一根因，统一修复）

推荐方案：在 _on_order_update 收到 "filled" 时，不立即删除追踪记录，也不立即 set event，而是标记为"等待 userFills 确认"状态。收到对应 userFills 后，用真实 px/sz 更新，再 result_event.set() 并删除追踪。

设置短超时（如 1 秒），若 userFills 超时未到，再降级为 HTTP 查询。

Bug 5（线程堆积）

用 threading.Event 替代 time.sleep，订单解决时通知超时线程提前退出，或改用单一 ScheduledExecutorService 风格的定时器线程池。

Bug 6（状态不一致）

平仓 DB 更新失败时应将仓位从内存恢复（或保留在内存中），并触发 Lark 告警，而不是静默失败。

Bug 3（数据竞争）

修改 tracking 字段时持有 _lock，或将 tracking 的字段改为线程安全类型。