这是一个非常关键的设计问题。根据交易系统的常见最佳实践，强烈建议在调用第三方订单接口“之前”就创建持仓数据库对象（或至少预留记录），但需要配合一个明确的“状态机”来管理其生命周期。
这样做的核心原因是：保证本地数据记录的先发性和完整性，以应对异步、可能失败的外部操作。
📊 为什么要在“下单前”创建？
下表对比了“下单前”与“下单后”创建的利弊：
| 时机 | 优点 | 缺点与风险 | 结论 |
|---|---|---|---|
| 下单前创建 | 1. 本地记录始终存在：任何操作都有迹可循。 2. 立即获得 position_id：可用于关联订单、风控等。3. 状态驱动：通过状态字段清晰跟踪生命周期，易于处理异步通知和异常。 |
可能产生“幽灵持仓”（下单请求最终失败）。 | 推荐。通过状态机可完美管理“幽灵持仓”，利远大于弊。 |
| 下单后创建 （等异步通知） |
理论上可保证持仓记录100%对应成功订单。 | 1. 数据空洞期：下单后到通知前，系统无记录，难以追踪、管理、展示。 2. 关联困难：订单回调处理逻辑复杂，需反向关联和创建持仓。 3. 异常处理复杂：若通知丢失，持仓永远无法创建。 |
不推荐。会导致系统状态不完整，增加复杂度。 |
正文完
