CTP接口先推送委托更新，再推送成交更新，pos更新是在成交更新推送时完成。如果在收到委托状态更新为全部成交后立即按当前pos发出平仓单，数量可能不正确

标准写法

VeighNa CTA 示例策略的标准模式是：交易信号和下单逻辑写在 on_bar 中，self.pos 也只在 on_bar 里读取。

def on_bar(self, bar: BarData) -> None:
    """K线回调：基于 self.pos 做交易决策"""
    if self.pos == 0:
        if self.cross_over:
            self.buy(bar.close_price + 5, self.fixed_size)
        elif self.cross_below:
            self.short(bar.close_price - 5, self.fixed_size)
    elif self.pos > 0:
        if self.cross_below:
            self.sell(bar.close_price - 5, abs(self.pos))

这个模式之所以可靠，是因为：

• on_bar 由 K 线驱动，与委托/成交回报异步解耦
• 等下一根 K 线到来时，之前的成交回报早已推送完毕，self.pos 已是准确值
• 不存在"委托回报先于成交回报"的时序问题

什么时候会遇到时序问题

只有在非标准写法下才需要关注回报顺序，比如：

• 在 on_order 中收到 ALLTRADED 后立即按 self.pos 平仓
• 在 on_trade 中立即反手
• 高频场景下不等下一根 K 线、需要在回报回调中即时反应

这类个性化需求中，CTP "先委托回报、后成交回报"的推送顺序就会导致 self.pos 滞后，需要自行处理细节，例如：

• 用 order.traded（委托自身的已成交量）代替 self.pos 作为下单数量依据
• 把仓位相关逻辑放到 on_trade 中（此时 pos 已更新）
• 参考 TargetPosTemplate 的交易状态机写法，确保没有在途委托时才重下单

总结

参考来源：order-callbacks.md、position-holding.md