13a0e7d580
删除了多个不再使用的文档和代码文件，包括交易更新推送、条件订单推送、REST API 文档、WebSocket API 文档及相关的策略分析文档。这些文件的移除有助于清理代码库，确保项目的整洁性与可维护性。
4.7 KiB
4.7 KiB
订单记录入库方式演变说明（为何 12 号下午之前能对上、后来对不上）
时间线（按 Git 提交）
- 2月12日及之前：订单能对上一些。
- 2月12日下午：提交
0df841c只改了止盈比例和配置/前端，未改入库逻辑。 - 2月14日：
3d9f58f（使用自定义订单号）、11cd55f（client_order_id 支持）—— 下单带newClientOrderId，补建逻辑收紧。 - 2月16日：
5154b49引入 pending 预落库 + UDS 按client_order_id完善。 - 2月17日：
415589e等增强 UDS/同步；UDS 开仓 FILLED 时无 clientOrderId 直接 return，不完善。
12 号下午之前的入库方式（能对上的原因）
-
没有 pending 预落库
开仓流程是：REST 下单 → 轮询等待成交 → 成交后直接Trade.create(entry_order_id=order.get("orderId"), client_order_id=order.get("clientOrderId"), ...)。 -
完全依赖 REST 返回
entry_order_id来自 REST 的orderId，一定能拿到。client_order_id来自 REST 的clientOrderId，当时未传newClientOrderId，可能是币安自动生成或空。
-
User Data Stream 不参与开仓落库
当时 UDS 主要做平仓回写；开仓是否落库只取决于 position_manager 里 REST 成交后那一次Trade.create，链路简单，所以容易和币安对上。
后来的改动（导致对不上的可能原因）
-
2月14日
3d9f58f- 下单时带
newClientOrderId（SYSTEM_ORDER_ID_PREFIX+ 时间戳）。 - 补建缺失持仓逻辑收紧：只补建「clientOrderId 带系统前缀」或「有止损/止盈单」的仓位；手动单、无前缀单不再自动建记录。
- 下单时带
-
2月16日
5154b49- 先落 pending：开仓前
Trade.create(status="pending", client_order_id=..., entry_order_id=None)。 - 下单时把
client_order_id传给币安（new_client_order_id）。 - 成交后：优先用 UDS 推送的 clientOrderId 找到 pending，再
update_pending_to_filled填entry_order_id/价格/数量；若 UDS 未收到或推送里没有 clientOrderId，则跳过完善，pending 会一直缺entry_order_id。 - REST 端成交后也有「有 pending 则完善、否则新建」的兜底，但若 REST 超时/异常，就只剩「未完善的 pending」或没记录。
- 先落 pending：开仓前
-
2月17日
415589e- UDS 开仓 FILLED：若没有 clientOrderId，直接 return，不尝试用 orderId 做任何回填。
综合效果：
- 一旦 UDS 断连、丢包或推送里缺少 clientOrderId，pending 无法被 UDS 完善。
- 若 REST 端也失败（超时、异常、进程重启等），就会出现「币安有成交、系统只有 pending 或无记录」的情况，对不上。
已做的改进（本次）
-
同步接口按当前账号 API 拉取
使用Account.get_credentials(account_id)，不再用全局 config，多账号/多配置时订单能对到正确账号。 -
DB 无记录时自动全量
若该账号在 DB 中没有任何交易记录，同步时会自动按「全量交易对」从币安拉订单并创建/补全记录。 -
UDS 无 clientOrderId 时用 orderId 兜底
- 新增
Trade.update_pending_by_entry_order_id(symbol, account_id, order_id, entry_price, quantity)：- 若 DB 中已有该
entry_order_id则跳过； - 否则在该 symbol+account 下找「status=pending 且 entry_order_id 为空」的记录，若恰好 1 条则用本订单号/价格/数量更新。
- 若 DB 中已有该
- 在
user_data_stream中：开仓 FILLED 时若没有 client_order_id，不再直接 return，而是先尝试上述兜底；只有兜底也匹配不到唯一 pending 时才仅打 debug 日志。
- 新增
这样即使 UDS 未带 clientOrderId（或 listenKey 断连导致漏推），只要该 symbol 下只有一条待完善的 pending，仍能用 orderId 补上，减少「币安有、系统没有」的情况。
建议自检
-
配置
- 当前账号是否已配置 BINANCE_API_KEY / BINANCE_API_SECRET（同步用的是当前选中账号的 API）。
- 若使用「系统单」前缀：
SYSTEM_ORDER_ID_PREFIX是否与下单时一致（影响补建和区分系统单）。
-
对账
- 在前端选好账号后，用「同步订单」勾选「全量同步」、选 7 天或 30 天，先补全历史。
- 再用「校验与币安一致性」接口查看是否还有缺失/不一致。
-
日志
- 若仍有漏记，可查：
- UDS：开仓 FILLED 是否带
c（clientOrderId）、是否有「已用 orderId 兜底完善」。 - 同步/补建：是否有「创建新交易记录」或「补全 entry_order_id」的日志。
- UDS：开仓 FILLED 是否带
- 若仍有漏记，可查：