简介面向量化交易初学者与C开发者这份基于CTP官方接口的demo覆盖行情订阅、交易下单、K线生成及策略触发等核心环节并支持接入SimNow仿真环境进行模拟交易。整体代码逻辑简洁重点演示CTP API的调用方式与常见量化框架的搭建思路适合希望快速理解接口用法和策略回测流程的入门者学习。资源包共33个文件约1.94MB以cpp/h源码为主体辅以dll/lib接口库、csv行情与K线样本数据以及sln/vcxproj工程文件使用VS2013及以上版本即可直接编译运行。源码中将行情、交易、K线转换与策略模块拆分清晰目录结构便于对照学习。目前已有5759人学习。对入门者而言可直接编译运行并观察csv数据完成Tick到K线的转换同时基于现有框架扩展自己的交易策略有效缩短从接口认知到策略实践的学习路径。1. CTP简单Demo的真实价值把全链路跑通比把策略写对更重要用CTP接口做量化交易最让人上头的不是策略本身而是“接口根本跑不通”。我见过不少写了很长时间策略的人最后卡在连接、订阅、下单这第一步上连仿真环境都没登录进去。这个Demo的价值就在于它把行情订阅、K线聚合、策略触发、下单撤单串成了一条完整链路并且直接对接仿真交易环境。设计并不精巧但能让新手在几天内完整走通一次“行情→信号→下单→回报”的闭环。适合两类人一类想在实盘前把柜台接口链路摸清楚另一类写过策略但没碰过期货交易接口、需要一块安全试验田的人。下面不只是讲这个Demo怎么跑还会把复现时容易踩的坑提前摊开讲。2. 搞懂CTP接口的核心线程模型与回调机制是这个Demo能跑起来的前提2.1 MdApi与TradeApi的分工CTP接口在架构上把行情和交易拆成两套独立API这一点第一次接触的人往往忽略。MdApi管行情订阅TradeApi管交易、查询和订单操作。两套API各自维护独立的网络连接也各自有独立的回调线程。这个设计带来的直接后果是你在TradeApi里下的单和MdApi里收到的行情在时间上不存在严格的先后保证策略模块做数据对齐时必须有心理准备。这个Demo在选型上走的也是这条路行情一个线程、交易一个线程、策略计算放在业务线程里。没有引入复杂的消息总线就是简单的队列加锁。常见做法是行情回调里把tick推进一个线程安全队列业务线程从队列取出后交给K线聚合器聚合器按时间周期吐出bar给策略模块策略再调用TradeApi下单。这个分工把CTP的回调面和后端业务完全隔离是接口工程里最稳妥的起点。不要小看这个分工。很多人写过“单线程里既订阅行情又下单”的伪CTP demo短时间跑不出问题但行情一密集回调线程里的阻塞会造成行情延迟严重时会被前置机判定为异常连接而断开。正规的CTP工程几乎不会在回调函数里做耗时操作。这个Demo最大的意义就是帮你建立“回调只做轻量动作”的肌肉记忆。为什么不能单线程因为CTP的回调本身就是内部网络线程发出来的。如果所有逻辑都堆在主线程里回调一旦被业务处理阻塞网络包就得不到及时处理前置机发现客户端不响应会主动踢掉连接。所以Demo做线程拆分的本质是隔离业务线程卡死网络线程依然能收行情和回报。2.2 回调线程与业务线程之间怎么传数据CTP回调函数运行在API内部的网络线程上回调里直接做运算和直接发请求都是大忌。原因不复杂回调线程被阻塞底层网络包不能及时处理行情和交易回报都会堆叠。这个Demo能跑得稳关键在于回调到业务之间加了一道人肉队列。最常见的写法是回调函数里只做两件事——把数据放进线程安全队列或者置一个标志位然后立刻返回。业务线程从队列取数再做真正的计算。这个Demo也是这么干的行情类回调把tick推进一个队列交易类回调把order和trade推进另一个队列。这样回调线程的响应时间始终在微秒级不会反过来拖垮连接。队列的选择并不复杂。Python环境用queue.QueueC环境用mutex保护的std::queue或者无锁队列。真正要注意的是不要用list直接append而不管线程安全这在行情密集时会出现数据丢失或者崩溃属于经典翻车。这段代码我早期也写过后来把所有跨线程的数据流统一成queue问题就消失了。队列长度也要关注。如果业务线程的处理速度和行情产生速度不匹配队列会越撑越大要么内存膨胀要么消费到过期的数据实时性崩塌。一般做法是给队列设一个上限比如最多存5000条tick超过就丢弃最老的并记录警告日志。这个上限取决于你订阅的品种数量和业务处理耗时没有固定值。仿真环境行情密度不高设大一些没事实盘订阅十几个品种的tick量会大很多必须做流控。2.3 Demo的模块组织方式这个Demo的目录组织按功能拆行情、K线、策略、交易四块是分开的。行情模块只负责接收tick并对外推送K线模块订阅行情模块的数据做周期聚合策略模块监听K线的更新输出信号交易模块把信号转成具体报单。这样拆的好处很明显任何一个模块要替换或者调试都不影响其他模块。举个实际例子。你只关心K线数据想拿它做回测和离线分析那只需要行情和K线两个模块不需要启动交易模块。你是做高频的想对每一笔tick做出反应只需要改策略模块的触发粒度K线和交易模块都不用动。分层的价值就是把CTP的复杂回调面包装成一个简单的数据流接口让策略编写者不被接口细节牵住。K线模块在Demo里一般按时间窗口聚合比如60秒或者5分钟。行情模块每收到一个tickK线模块就更新当前bar的最高价、最低价、最新价和累计成交量窗口结束的时候把bar推送出去。具体实现上用一个bar结构体记录时间、开高低收、持仓量和成交量。每个tick进来先判断是否跨过窗口边界跨了就封存前一根bar并开启新bar否则更新当前bar的字段。听起来简单但在实盘环境里边界条件会被放得很大尤其是集合竞价那几秒钟的行情很多tick时间戳是乱的不做过滤的话K线会错乱这个坑放到避坑章节细说。数据流的方向也要明确。行情模块只往外发布数据不接收任何指令策略模块订阅K线数据流只输出信号交易模块接收信号后发请求。如果方向反了比如策略直接操作行情模块的内部实例代码会纠缠在一起没法调试。借助事件回调或者一个轻量的消息中心可以解决但Demo阶段用一个简单的观察者模式就够用了。3. 连接仿真环境跑通模拟交易从配置到下单的完整步骤3.1 前置机地址、账号与API版本的选择把这个Demo跑起来第一步是连接仿真交易环境。仿真环境开通后会给你一个测试账号和一组前置机地址行情前置和交易前置是分开的两个地址都要填对。这里最容易出错的地方是有人把行情地址填到交易API里导致交易连接一直建立不起来日志反复出现超时。API版本的选择也有讲究。如果Demo用的是较老的CTP接口版本登录仿真环境时不需要传额外认证参数RegisterFront之后直接ReqUserLogin就能登录。但近几年的仿真环境普遍要求支持穿透式监管的接口版本要配置appId、authCode。如果你用的API版本和仿真环境要求不一致登录回报里会带错误码典型的就是“客户端认证失败”。这种时候通常不是账号或密码错了而是API版本和认证配置的问题。账号和密码之外还有几个容易被忽略的配置项。合约代码必须是标准格式如au2512这种大小写敏感客户端编号不能重复同一个账号在多个进程里用同一个ClientId登录后登录的会把先登录的踢下线查询频率有限制超出会被前置机拒绝需要控制请求节奏。仿真环境比实盘宽松但提前养成好习惯能省掉不少血泪。我一般会建议先把日志级别调成全量输出登录不成功时去看错误码错误码基本都能直接对到具体问题。不要盯着屏幕猜也别急着改账号密码先看前置机有没有连通再看API版本对不对。3.2 登录与行情订阅核心代码走一遍登录和行情订阅是这个Demo最基础的一段代码下面的伪代码核心逻辑和Demo是一致的按CTP接口的调用顺序写实际工程里要加上重试和状态判断。# 行情接口初始化与登录 md MdApi() md.RegisterFront(tcp://203.0.113.10:11121) # 仿真交易行情前置地址 md.Create() md.ReqUserLogin(userdemo_user, passworddemo_pass, broker8888) # 等待 OnRspUserLogin 登录成功回调再继续订阅 md.SubscribeMarketData([au2512, rb2510])逻辑说明RegisterFront先把前置机地址注册进去Create开始建立网络连接连接成功后自动触发登录。登录成功是在回调里通知的所以订阅行情之前必须要等一个登录完成信号否则订阅请求会被拒绝。回调函数里做的事情很简单收到登录成功就把事件置为true业务线程wait到之后再调用SubscribeMarketData。参数说明前置机地址的IP和端口以仿真环境开通页面给出的为准不同环境差异很大合约代码格式是“品种代码到期年月”示例中au2512代表黄金2025年12月合约rb2510代表螺纹钢2025年10月合约。示例地址是示意用的测试网段地址实际跑的时候要替换成你账户对应的真实前置机地址。建议先只订阅一两个品种等整个链路通了再扩品种这样出问题的时候定位范围会小很多。3.3 K线聚合与策略触发从tick到信号整个Demo里最有价值的一段其实是tick数据到K线信号的聚合链。行情订阅成功后每个合约每秒可能收到多个tick每条tick带着最新价、成交量、持仓量等字段。直接拿tick做策略不是不行但大多数策略都要先按周期聚合信号才稳定。聚合器在Demo里可以这样实现BAR_PERIOD 60 # 每根K线60秒 def on_tick(tick): global current_bar ts tick.time if current_bar is None or ts - current_bar.start_time BAR_PERIOD: if current_bar is not None: emit_bar(current_bar) # 封存前一根bar推给策略模块 current_bar Bar(start_timets, opentick.last, hightick.last, lowtick.last, closetick.last, volumetick.volume) else: current_bar.high max(current_bar.high, tick.last) current_bar.low min(current_bar.low, tick.last) current_bar.close tick.last current_bar.volume tick.volume逻辑说明每个tick进来先比对时间跨过窗口就封存当前bar并推给策略否则更新当前bar的开高低收和量。这里的tick.time指K线的起始时间实际要考虑合约的集合竞价阶段和接口时区配置。如果时间戳对齐没做对聚合结果会乱。参数说明BAR_PERIOD单位是秒改成300就是5分钟K线改成1800就是30分钟K线。要注意这个聚合方式和交易所正式K线对不齐的地方夜盘和白盘切换边界、集合竞价开盘价、涨跌停板附近的tick过滤简单Demo里往往不做特殊处理回测对比时会对不上这是正常现象。策略模块在接收到bar之后做的事很直接维护一个简单均线序列上穿就发买入信号下穿就发卖出信号。Demo里信号生成和下单是同步的没有信号队列实盘里如果信号抖动会造成无意义频繁下单。常见缓解办法是加一个最小触发间隔参数比如两分钟内同一方向的信号最多触发一次。3.4 回测与参数验证K线聚合和策略触发跑通之后建议先别急着下单而是把策略放在历史数据上验证。仿真环境实时行情给的是每秒几十条的tick想验证一个周期策略是否可行最简单的办法是把聚合器输出的bar落盘然后回放。这个Demo里K线模块可以考虑加一个文件落地功能把每天的bar追加到CSV里之后用同一套策略代码读CSV做回测。回放的实现不复杂。把CSV里的bar按时间顺序喂给策略模块保持和实时调用一样的接口签名。策略模块完全不感知数据来源是实时还是回放这就是模块隔离带来的好处。参数上比如移动平均窗口用20还是50最小触发间隔设多少秒都可以在回放里试出来。仿真环境的好处是参数错了也不会亏真钱可以大胆试。这里有个取舍Demo阶段不建议把回测框架做得很重成本会很高。能用最少的代码验证“策略逻辑确实能产生信号”就够了过多优化反而会推迟你接入真实行情和交易链路的时间。4. 交易链路怎么搭下单、撤单与回报处理4.1 下单接口与参数分析策略产生信号后交易模块要做的是调用TradeApi的下单接口。这个接口的入参比很多人想象得多其中对成败影响最大的有方向、开平标记、价格条件、手数。方向是买还是卖开平标记是开仓还是平仓价格条件是限价还是市价手数是一次下几手。仿真环境里填错不会造成资金损失但养成乱填的习惯换到实盘会出事。一份典型的下单请求在代码里是这样组织的req { OrderRef: 1, # 报单引用客户端内唯一 Direction: Buy, # 买卖方向 CombOffset: OPEN, # 开仓 CombHedgeFlag: Speculation, # 投机属性 LimitPrice: 0, # 限价价格市价单不用填 VolumeTotalOriginal: 1, # 原始报单手数 PriceType: Limit, # 价格条件 InstrumentID: au2512, # 合约代码 } trade.ReqOrderInsert(req)逻辑说明这些字段合起来构成一笔完整报单。OrderRef是客户端内报单编号每次下单都要递增重复会导致回报错乱。后续从回报中定位这笔单靠OrderRef和交易所生成的报单编号配合完成。参数说明LimitPrice填0且PriceType为Limit时很多仿真环境会直接拒单因为限价单价格不能为0。市价单不需要填价格但部分品种不支持市价单需要在仿真环境里先试出来。开平标记如果和持仓方向不匹配会触发接口返回“平仓手数超过持仓量”在仿真里很常见。下单过程是异步的ReqOrderInsert返回后不会立刻得到确认。正确做法是先把OrderRef递增然后等OnRspOrderInsert回调。如果回调的错误字段不为空说明下单被拒否则等OnRtnOrder和OnRtnTrade确认这笔单的最终状态。千万不要认为下单函数没有抛异常就是成功了。4.2 回报与成交的处理下单成功后CTP接口分两条线给你回报。一条是报单回报OnRtnOrder标明这笔单当前状态是已报、部成、全成还是已撤另一条是成交回报OnRtnTrade每产生一笔成交推送一条。两条线的顺序不严格尤其部分成交时会发生多次OnRtnTrade但报单回报只推一次。Demo里需要维护一个报单状态表用OrderRef和报单编号做索引每次回报都更新进去。复杂度在于撤单请求也会产生报单回报撤单成功的回报里状态是“已撤”这时你不应该改动持仓量因为撤掉的部分没有成交。判断一笔报单是否真实成交必须看成交回报里的累计成交量不能只看报单回报的状态。这个细节新手特别容易忽略一看报单状态变成“全成”就更新持仓等撤单回报来了又把持仓删了逻辑就乱了。状态表不用很复杂每个报单维护“已报数量、已成交数量、状态、方向、开平标记”即可。OnRtnTrade来了累加已成交数量OnRtnOrder来了更新状态。已成交数量等于报单手数时这笔单才算完结。撤单调用ReqOrderCancel传入原报单编号和交易所报单编号撤单请求同样进入状态表。这个一点点积累的状态表就是后续做风控和日内持仓管理的基础。4.3 持仓和资金查询交易模块只负责下单不够一个完整的循环必须有持仓和资金查询用来判断策略信号能开多少手、平多少手。CTP里对应的是ReqQryTradingAccount和ReqQryPosition。查询是异步的回报里返回账户可用资金、冻结资金、持仓列表和可用手数。Demo里资金查询的用法trade.ReqQryTradingAccount() # 等待 OnRspQryTradingAccount 回调 def on_account(account): balance account.Balance available account.Available # 策略根据 available 计算可开手数逻辑说明查询结果通过回调返回是账户静态信息快照包含总权益、可用资金等。持仓查询一样返回所有持仓明细每个持仓字段里有买持仓量、卖持仓量、可用量、今仓和昨仓。利用这些字段能算清楚还能开多少手以及平今、平昨分别该填什么开平标记。参数说明期货的今仓昨仓机制是特有的概念不同品种对平今平昨处理不同。仿真环境里建议先平昨避免报“平今手数超过持仓量”。查询返回的是时点快照不要在报单前临时发查询又立刻下单中间时间差可能让持仓信息过期。更稳的做法是每笔报单完结后主动更新本地持仓表与回报不一致时再触发查询修正。这个Demo在简单场景里够用实盘做严格风控还需要冻结和未成交报单的联动计算。5. CTP Demo的避坑排查五个常见翻车现场提示下面这五条都是我在复现和改造CTP Demo时真实踩过的坑每一条都按“现象→原因→解决”来写排查顺序也基本按这个来。5.1 登录一直不回调现象MdApi和TradeApi的初始化都调用过了程序启动以后日志只打了一行“正在连接前置机”接着等了很久也没看到连接成功回调触发命令行上没有任何报错就像卡住了一样。很多人在这一步会反复注销重登但问题往往不在账号。原因最常见的是前置机地址填错了。行情前置和交易前置是两个不同的地址如果填串了某一个API就会一直处在等待连接的状态没有任何错误提示。其次是本地防火墙或网络限制到前置机端口的TCP连接这在公司网络里尤其常见。还有一个容易被忽略的是API版本和前置机要求不匹配老版本客户端和新的前置机握手失败但不会在日志里明确报出来。解决先用网络工具测一下前置机端口是否可达。通了之后再看日志里有没有握手失败的记录尝试把API版本替换成环境要求的版本。如果还不行把日志级别调到全量观察底层网络包是否发出去、有没有超时记录基本能定位是网络问题还是协议层问题。这些步骤做完大部分登录卡住的问题都能解开。5.2 订阅行情时返回合约不存在现象订阅报价调用后回调里没有返回成功消息而是带了一条错误明确写合约代码不对。有时候症状更隐蔽订阅没有报错但行情回调里永远没有这个合约的数据像被静默丢弃了一样。原因合约代码写错是最直接的。标准格式是“品种代码到期年月”如au2512但有的人会写成au或者Au2512大小写和缺字段都会导致订阅失败。另一个容易踩的坑是仿真环境里很多合约已经到期摘牌而代码里硬编码的合约代码来自几个月前的实盘配置自然匹配不上。解决在登录完成之后先调用一次合约查询接口把返回的合约列表打印出来确认目标品种的当前主力合约代码。把合约代码放到配置文件而不是硬编码到代码里换月时只改配置。可以在合约查询回报里额外建一个“品种→主力合约”的映射表订阅失败时回退到映射表里的主力合约重新订阅。5.3 下单被拒流控报错现象程序跑了一段时间后突然连续报同一个错误码查询账户和行情刷新都正常但只要发交易类请求就立刻返回失败错误信息里通常带“请求太频繁”或者“操作过于频繁”。原因CTP前置机对单位时间内的请求数量有限制。Demo脚本里常见的情况是在循环里反复调用账户查询或者持仓查询两次查询之间没有加间隔一口气发了几十条请求。另一种情况是策略信号在短时间内频繁触发下单请求成串发送直接顶到流控阈值。解决给所有交易类请求加一个统一发送节流器全局记录上次发送时间间隔小于500毫秒就排队等候。查询类请求做去重比如上次查询的回报还没回来就没必要再发一次。日志里要记录错误码的触发来源前置机流控通常几秒钟就恢复交易所侧流控需要等更长时间。养成这个习惯之后从Demo切到实盘会少踩很多坑。5.4 K线在集合竞价阶段乱跳现象每天早上开盘那几分钟K线聚合模块生成的bar和行情软件的K线对不上开盘价特别离谱甚至会出现一根上下影线长得离谱的bar成交量也异常放大。原因集合竞价阶段交易所会广播虚拟撮合的tick以及市场试验数据这些tick的时间戳和连续竞价阶段不在同一条时间线上。简单的聚合逻辑没有对这些tick做区分把它们全部当成有效数据K线自然就乱了。解决在聚合器进入新bar之前加一个tick有效性过滤规则——判断当前是否处在集合竞价阶段这段时间的tick不进入聚合窗口。或者对tick的时间戳做一次排序后再送入窗口丢弃逆序或者不连续的数据。这个过滤逻辑要放在K线模块的入口处策略模块不感知这些细节保证策略拿到的bar是干净的。5.5 撤单时报“未知报单”现象下单成功之后策略要撤这笔单调用撤单接口却返回“未知报单”错误日志里明明有这笔单的下单记录。原因撤单请求里传的报单编号不对。CTP有两层编号客户端本地OrderRef和交易所生成的OrderSysID。撤单时如果没有带上交易所侧生成的OrderSysID前置机在交易所侧找不到这笔单就会返回未知报单。另一种情况是撤得太快报单还没被交易所系统登记就被撤了。解决在收到OnRtnOrder确认报单已经进入交易所系统之后再撤单撤单参数里带上OnRtnOrder返回的交易所报单编号。在本地维护一张“本地OrderRef→交易所OrderSysID”的映射表所有撤单都通过这个表找到正确的编号。日志里记录两条编号的对应关系排查的时候一眼就能看出问题在哪。撤单失败后不要立刻重发先查一下报单最新状态如果已经全部成交撤单失败是正常的。6. 从Demo到可用框架状态机、重连与日志三板斧6.1 状态机管理Demo跑通之后下一步是给连接加状态管理。CTP连接有“未连接、已连接、已登录、已就绪”几个状态建议做一个明确的状态机把登录后的每个动作都挂在状态机上。比如“未登录”状态下禁止下单“已断开”状态自动触发重连。这能让程序在异常情况下保持可预测的行为。状态切换时打一条日志记录旧状态、新状态和触发原因后续排查会非常直观。6.2 重连机制与日志网络断开在实盘里是完全正常的。要处理的情况是行情线程断开但交易线程还活着或者两者同时断开。重连逻辑要独立不依赖业务线程的调度。日志方面建议在关键节点都打一条结构化日志包含时间戳、操作、回报状态之后定位问题基本靠日志就能完成。重连时要小心的是不要重复登录同一个账号导致互踢下线。从那以后我再写CTP相关程序都会强制先走一遍“连接、登录、订阅、下单、回报、撤单”的最小闭环日志里每一步都有迹可循再往上面加策略和自定义逻辑。这个习惯让CTP这个黑匣子变得透明希望你也能在仿真环境里先把这套闭环走通再考虑上实盘。希望帮到你。本文还有配套的精品资源点击获取