29 lines
2.7 KiB
Markdown
29 lines
2.7 KiB
Markdown
### S1. 券商快照延迟时，本地委托锁会被清空并可能重复下单
|
||
|
||
- 位置：`strategy/trend/order.py:54-92`、`strategy/trend/boot.py:127-130,157-162`、`strategy/trend/open.py:23-25`
|
||
- 证据：下单成功后 `OrderBook.place()` 会立即加入本地 pending 和方向锁，但下一轮 `refresh()` 会完全用券商快照重建 `data` 与 `lock`。若券商快照尚未出现刚提交的订单，本地 pending 会直接丢失。开仓候选只排除当前持仓，不排除 `State` 中的待成交底仓，最终仅依赖已经被清掉的 `busy()` 锁。
|
||
- 影响：接口存在可见性延迟时，同一证券可能在连续轮次重复提交买单；卖单和补仓也存在相同锁丢失窗口。
|
||
- 建议：刷新时合并尚未超时且券商未确认的本地 pending，而不是覆盖；按本地订单号查询确认后才能移除。开仓筛选同时检查状态机中的 `base_status`。
|
||
|
||
|
||
### H3. 撤单、拒单、废单和部分成交不能驱动状态机正确收敛
|
||
|
||
- 位置：`strategy/trend/state.py:142-162`、`strategy/trend/order.py:14-17,61-92`
|
||
- 证据：状态对账只把“匹配订单全部为状态 56”视为完成，其余均保持 `ING`；订单被过滤或消失时，已有持仓的补仓状态不会变为失败或撤销。文件中虽然定义了 `FAILED`、`CANCELED`、`UNKNOWN`，但没有完整迁移逻辑。
|
||
- 影响：失败的补仓仍会消耗 `added_num`，状态可能永久停留在处理中，重启后也无法可靠恢复。
|
||
- 建议：建立完整 QMT 委托状态映射，按实际成交数量处理全成、部成、已撤、废单、拒单和未知；消失订单需二次查询确认。
|
||
|
||
|
||
### M1. IPO 仍只依赖本地锁，存在重复申购窗口
|
||
|
||
- 位置：`strategy/ipo/boot.py:49-65`
|
||
- 证据：下单成功后才写锁；未查询券商当日委托或成交记录。进程若在下单成功与写锁之间退出，或锁文件被删除，下一次调度会再次申购。
|
||
- 影响：同一证券可能重复发送申购请求，安全性依赖券商端是否拒绝重复申购。
|
||
- 建议：本地锁只作为快速缓存，下单前以券商委托/成交记录做最终幂等校验。
|
||
|
||
### M6. 策略成本使用提交时行情价，而非实际成交价
|
||
|
||
- 位置：`strategy/trend/open.py:80-86`、`strategy/trend/positions.py:186-192`
|
||
- 证据：底仓和补仓在订单刚提交成功时就把 tick 价格写为成本，没有根据成交回报更新实际成交数量与均价。
|
||
- 影响：滑点、部分成交或拆单时，后续盈亏率、止盈网格和补仓层级基于不准确成本。
|
||
- 建议：提交阶段只记录订单标识；订单完成对账后从成交或真实持仓均价更新成本和数量。 |