Java开源量化交易平台：CTP接入、事件驱动与回测实盘一致性设计

简介：面向程序员与量化交易开发者的基于Java的AI开源量化交易平台，可替代文华、MC、金字塔等商业软件，支持期货、股票、外汇、数字货币等多种交易场景，具备历史回放、策略研发、模拟交易和实盘交易能力，兼顾全自动与半自动操作，适合需要自主搭建程序化交易系统的技术团队或个人研究。资源包为zip压缩格式，共578个文件，大小约1.83MB，以407个Java源码文件作为后端核心，配合62个JS、24个Vue前端文件构建交互界面，另有XML、JSON、yml等配置文件及Dockerfile部署文件，结构清晰，便于二次开发与本地化部署。目前已有195人浏览学习，适合有一定Java基础、希望深入理解量化交易平台架构的开发者。通过学习可以获得完整的平台源码与配置方案，梳理从策略研发到实盘对接的模块设计，结合历史回放功能验证交易逻辑，为后续功能扩展和自定义策略提供可落地参考。

1. 为什么说它是能“秒替”文华/MC/金字塔的Java量化平台

做期货CTA和股票日内的人，大多被文华、MC、金字塔的“黑匣子”策略编辑器和受限的数据接口折磨过。这套基于Java的AI开源量化交易平台，一上来就把交易链路拆成了历史回放、策略研发、模拟交易、实盘交易四个独立模块，而且把CTP、行情推送、策略引擎、风控、下单这五层解耦开，程序员可以直接读源码改逻辑。对我来说，它真正解决的是两个问题：一是策略从回测到实盘的逻辑一致性，不用再怀疑回测是“未来函数”堆出来的；二是半自动场景下，AI信号先出，人工确认再下单，既保留了程序执行的纪律性，又给了交易员最后一道拦截。适合手里有Java基础、受够了商业软件封闭生态的程序员和量化爱好者，也适合要在期货、股票、外汇、币圈多市场共用一套策略框架的团队。

2. 平台核心架构：从CTP接入到策略引擎的分层设计

2.1 技术栈与模块划分

从项目源码和配置文件能看出来，这套平台不是把交易逻辑揉在一个大类里的单体应用，而是按“数据、决策、执行”三个维度拆模块。底层用Java NIO和非阻塞队列处理行情流，上层用Spring管理策略Bean的生命周期，界面层则是JavaFX做的桌面客户端。核心的交易部分不依赖任何商业闭源库，CTP接口用的是官方原生JNI封装，行情和交易通道分开连，这点很重要，因为CTP的行情服务器和交易服务器本来就是两个地址。

模块划分大致是：

• 接入层：负责连接行情源（CTP、穿透式柜台、模拟盘）和交易通道，把原始TCP报文转成统一事件。
• 策略引擎：加载jar包或脚本策略，管理策略的初始化、行情回调、定时任务、下单请求。
• 风控模块：在策略和下单通道之间插入一层，检查手数限制、单日亏损上限、频率限制。
• 回放引擎：把历史tick或K线按时间顺序重新推送给策略，用于回测。
• 账户中心：管理真实账户和模拟账户的资金、持仓、委托、成交。
• GUI与监控：行情图表、持仓盈亏、策略状态、日志面板。

我建议拿到源码后先从engine和broker两个包看起，一个管策略生命周期，一个管交易通道，剩下的都是围绕它们的细节。

2.2 事件驱动与行情/交易接口的解耦

平台的核心是事件驱动模型。行情到达后，不是直接调用策略的方法，而是先包装成MarketDataEvent，放到一个链式分发器里。分发器会按照“风控前处理 → 策略回调 → 风控后处理 → 下单指令生成”的顺序流转。这样做的好处是，策略里不需要关心行情来自实盘还是回放，也不需要在策略代码里直接动账户下单接口。

public interface BarHandler { // 每根K线结束时触发，isReplay为true时表示来自历史回放 void onBar(Bar bar, boolean isReplay); } public class StrategyBase implements BarHandler { protected OrderSendResult sendOrder(OrderRequest req) { if (getContext().isReplayMode()) { // 回放模式下只做模拟撮合，不真正发单 return getContext().getMatchEngine().match(req); } return getContext().getBroker().sendOrder(req); } }

回放和实盘用的是同一套sendOrder入口，只是底层broker不同。这段代码的逻辑说明：策略层只感知sendOrder这个方法，至于内部走的是回放撮合还是真实CTP通道，由运行环境决定。参数isReplay是回放引擎从环境变量里读到的标识，matchEngine里封装了tick级别的撮合规则，比如按对手价成交或按盘口深度成交。这样设计之后，回测和实盘共用一套策略代码，杜绝了“回测一个样、实盘另一个样”的典型翻车点。

接口解耦还体现在账户资金查询上。策略里取可用资金，统一调用getContext().getAccount().getAvailable()，而不是直接读某个全局静态变量。我实际拆代码时发现，这个Account对象内部维护了一个“快照 + 增量”的缓存，实盘时每次交易回报或资金变动都会更新快照，回放时则从历史数据重建账户状态。这种设计在回测时能准确模拟强平和手续费扣除，做高频回测时不会出现资金越算越多的情况。

2.3 配置文件与启动流程

平台用了一个application.yaml做主配置，分local、backtest、simulate、live四套profile，启动时通过-Dspring.profiles.active=backtest切换。这里贴一份我常用的回放配置骨架：

server: port: 8080 quant: mode: backtest # backtest / simulate / live >public class MaCrossStrategy extends StrategyBase { private MaIndicator fastMa; private MaIndicator slowMa; private PositionManager pm; @Override public void onInit() { // 用策略参数中的fast/slow作为周期 fastMa = new MaIndicator(getParam("fast", 5)); slowMa = new MaIndicator(getParam("slow", 20)); pm = new PositionManager(getContext()); } @Override public void onBar(Bar bar, boolean isReplay) { fastMa.update(bar.getClose()); slowMa.update(bar.getClose()); // 金叉且当前无持仓时做多 if (fastMa.getValue() > slowMa.getValue() && !pm.hasPosition("long")) { OrderRequest req = new OrderRequest(); req.setSymbol(bar.getSymbol()); req.setDirection(OrderDirection.BUY); req.setOffset(OrderOffset.OPEN); req.setVolume(1); int orderId = sendOrder(req).getOrderId(); log.info("open long at {} via {}", bar.getClose(), orderId); } } }

这段代码演示了最小可用策略。getParam在策略启动时从yaml的strategy.params里注入参数，如果yaml没写就用默认值。pm.hasPosition("long")是通过账户中心的持仓对象判断当前是否已有净多头，避免信号连续触发导致重复开仓。sendOrder返回一个OrderSendResult，里面有订单ID和错误信息，这里我习惯把orderId打进日志，后续排查撤单、部分成交都要靠它。

如果你要做半自动场景，onBar里不要直接sendOrder，而是把信号写进一个待确认队列：

if (signal == SIGNAL_BUY) { SignalEvent evt = new SignalEvent(bar.getSymbol(), "BUY", bar.getClose()); getContext().getConfirmationQueue().offer(evt); }

这样GUI上会弹出一个窗口，显示“策略建议做多1手，价格3500”，由人工点确认后再真正发单。半自动模式下，策略永远不能直接下单，所有指令都必须经过确认这一关，这是平台在风控上的一个关键设计。

3.2 历史回放的参数与数据源设置

回放质量直接决定策略可信度。平台支持三种数据源：本地文件、CTP历史行情、外部导入的csv。本地文件是首选，因为它不受网络影响，回放速度最快。一套合格的本地数据应该是这样组织的：

data/ rb2410/ 20240101.tick 20240102.tick 20240103.tick

每个tick文件一行是一条行情，包含时间戳、最后价、买一价、买一量、卖一价、卖一量、持仓量字段。如果只有分钟K线，平台也可以按K线做模拟撮合，但成交价精度会差一截。我一般从期货公司官网或第三方数据商把每日tick行情导出成csv，再用平台自带的CsvToTickDataTool转成二进制格式，转换命令是：

java -cp quant-platform.jar com.quant.tools.CsvToTickDataTool \ --input ./csv/rb2410.csv \ --output ./data/rb2410/20240101.tick \ --symbol rb2410 \ --date 20240101

参数--symbol是合约代码，--date是交易日，工具会把csv里的时间字符串转成平台的纳秒时间戳，并按成交量过滤掉异常快照。转换完成后，yaml里>[2024-01-15 09:31:00] BUY OPEN rb2410 5手 @ 3502.0 [2024-01-15 10:15:00] SELL CLOSE rb2410 5手 @ 3520.0 profit: 18.0*5 - 手续费 32 = 58.0 元

平台会把每次平仓后扣除手续费和滑点的净额标出来，方便你直接对比策略在不同手续费参数下的敏感性。如果看到连续几笔亏损单的亏损金额恰好等于手续费加滑点，那不是策略失效，是策略在噪音区间反复打脸，这种情况应该先加过滤条件再去调指标周期。

回放引擎还提供了一个“盯盘模式”，能够像实盘一样一根一根K线地推。我经常用这个模式观察策略在极端行情下的表现，比如某根K线突然跳空高开，策略是否在开盘价上追单。跳空场景下opponent撮合会直接按跳空后的第一笔对手价成交，这会让滑点成本瞬间吃掉好几笔利润。如果你实在不想被跳空伤害，可以把match.price-type改成same-as，但这属于自欺欺人，因为实盘遇到跳空必然按对手价成交。

4. 模拟交易与实盘切换：半自动和全自动的操作边界

4.1 模拟交易环境与风控参数

模拟交易是收费实盘的完整预演。平台连的是CTP的simnow或券商的仿真柜台，行情、报单、成交回报、资金变动全部走真实交易所协议，只是不产生真实资金。在这个环境里，策略代码不需要改动，只需要把quant.mode从backtest切到simulate，然后配置模拟账户的账号密码。

quant: mode: simulate broker: type: ctp auth-code: ******** app-id: quant_client_test user: sim_user password: ******* flow-path: ./flows/sim/

这里的flow-path是CTP会话的流目录，用来保存登录后的会话状态。CTP要求每次客户端启动生成一个新的回话编号，平台会在flow-path下自动创建以时间戳命名的子目录。如果你把这个目录设为只读，或者手工删除了里面的文件，CTP会报“会话编号重复”错误。我一般会固定一个目录，然后在启动前清空一次，避免历史会话文件干扰。

模拟交易时的风控参数和实盘最好保持一致。平台里风控模块是可插拔的，默认打开四个过滤器：

我建议第一次上模拟盘时把max-orders-per-second调到2，就是为了逼自己暴露“信号重复触发”和“策略逻辑中未过滤的已发订单”这两个问题。模拟盘不会真亏钱，但会放大你策略里的算法bug。

4.2 半自动模式的“人工确认”机制

半自动模式是这套平台相对商业软件最有价值的地方。你在策略里产生的每一个信号，都会先进入一个待人工确认列表，GUI会显示信号来源策略、合约、方向、价格、建议手数、触发时间。人工可以在提示栏里看到信号附带的“策略置信度”——平台内置了一个简单评分器，基于当前信号与过去N次同类信号的历史胜率给出0到1的分值。高于0.7显示绿色确认按钮，低于0.3显示红色忽略按钮，介于之间则只显示原数据，不做任何颜色提示。

这套设计的核心在于，机器负责“想”，人负责“拍板”。人可以有最后5秒的冷静期，不被策略的追单情绪带动。我自己的规则是：人工确认时，不允许直接双击确认，必须按一下空格键锁定按钮，再点击“确认下单”，这就保证了每次确认都是有意识的动作。

人工确认后，还可以临时修改手数。比如策略建议开2手，你看盘口觉得流动性不够，可以改成1手再确认。这个操作不会影响策略内部的持仓记录，因为修改动作最终会同步回账户中心的“待执行委托”里。如果策略在人工确认期间，又发来一个反向信号，平台不会自动取消防问列表里的旧信号，但会在旧信号上打一个“已被新信号覆盖”的标记。这是为了避免人机纠缠导致的误操作，也提醒你要小心同一时刻多个策略产生冲突信号。

4.3 实盘切换前的检查清单

从模拟盘切到实盘，不是改一个配置文件那么简单。我把自己的检查清单列在这里，照着走一遍能挡掉大多数低级问题。

1. 检查CTP账号权限是否已开实盘交易权限，包括上期所、大商所、郑商所、中金所、能源中心的品种权限。某些品种（如原油、国际铜）需要单独验资和考试，模拟盘能下单不代表实盘也能下单。
2. 确认柜台模式是“即时”还是“预埋”。如果你在盘中用sendOrder发单，没问题；但是你在夜盘收盘后发单，某些柜台会拒绝，因为非交易时段不允许普通报单。平台支持把这类单子转成“预埋单”，需要在yaml里把broker.prematch.enabled设为true。
3. 校准时间源。实盘环境下，策略的本地时间必须由JVM内部时钟与行情服务器时间做对齐，平台会定期发出一个同步偏移日志。如果偏移超过500ms，下单时间戳会出现偏差，影响后续的撤单和条件单触发。
4. 实盘账号绑定的回调地址。CTP的私有流和公有流用的是同一个账号和密码，但回报回调的IP白名单必须先在期货公司备案。如果flow-path和本机IP不在白名单里，登录时能连上行情，但交易回报会断断续续。

我踩过一个坑：拿联调环境的auth-code直接去连实盘柜台的地址，结果CTP返回“不合法的会话”，日志里面BrokerId和FlowPath不匹配。后来意识到，实盘环境必须用独立的auth-code，代码里写死的是联调环境变量，必须从配置文件里改成实盘对应的值。从那以后，我每次切实盘都要先在终端跑一条netstat -apn | grep java确认出去连接的IP是不是实盘柜台，再放行资金。

5. 避坑指南：CTP连接、回放数据、平仓方向、并发下单的高频问题

5.1 现象：CTP登录后自动退出，日志报“RejectTThost”

原因：CTP的客户端认证（AppID和AuthCode）在每次连接时都会校验，如果你的进程之前已经用同一套账号密码连接过，并且没有正常登出，服务端会话表里还会残留旧会话，新会话就会被拒绝。 解决：先确认flow-path里有没有历史会话目录，有的话手动清空；然后在平台GUI的“连接管理”里点“安全登出”而不是直接关窗口。我写了个小脚本，在每次启动实盘前自动删除flows/live/下所有子文件夹，但保留latest软链接。

find ./flows/live/ -mindepth 1 -maxdepth 1 -type d ! -name "latest" -exec rm -rf {} +

5.2 现象：历史回放成交价格和当时实盘盘口明显不一致

原因：本地tick数据里可能混入了交易所的“截断快照”，比如某些合约在09:00:00后的第一笔快照带有上日收盘价标记，导致最后价和买卖一价不在同一价位。如果回放用的是opponent撮合，就会按这个失真价成交。 解决：转换csv数据时，增加一个过滤条件：时间戳小于指定交易时段首笔有效快照的数据一律丢弃。平台实现里有一个valid-tick-time参数，默认是开盘后3秒。如果策略是对秒级启动有要求的，把3秒调成1秒，并在回放报告里看“第一笔成交时间”是否与预期一致。

5.3 现象：策略平仓方向写反，导致“开仓+平仓”被同时挂出

原因：OrderDirection和OrderOffset的组合写错了。比如手里有2手多单，想平仓却发了BUY + CLOSE，CTP会直接返回“平仓手数超过持仓数量”；如果发了SELL + OPEN，则会变成反向开空，持仓变成4手。 解决：平台里封装了一个PositionManager，它会检查指令方向与当前持仓方向，如果冲突自动转换成CLOSE_TODAY或CLOSE_YESTERDAY。我建议所有策略都统一走pm.close(symbol, volume)方法，而不是底层直接构造OrderRequest。下面是正确写法：

pm.close("rb2410", 2, "makerOrCancel");

makerOrCancel是下单方式，表示委托类型是“挂单成交优先”。如果盘口无法立即成交，会撤销剩余部分，这能避免普通限价单挂在一边占用冻结资金。

5.4 现象：同一信号在tick级别重复触发，瞬间下了好几单

原因：策略里没有做“当前K线是否已处理”的判断。onBar回调每根K线都会执行一次，但是如果你在onTick模式里写的判断条件是“最新价突破”，那同一根K线内的几十个tick都会满足条件，每来一个tick就发一单。 解决：在策略基类里加一个去重标记：

@Override public void onTick(Tick tick) { if (tick.getTimestamp() == lastProcessedBarTimestamp) { return; } // 处理逻辑 lastProcessedBarTimestamp = tick.getTimestamp(); }

lastProcessedBarTimestamp是每个策略实例私有的字段，不用担心多策略并发。还有一个更稳妥的方式，是让风控模块的max-orders-per-second生效，但那只起兜底作用，策略逻辑层面必须做幂等。我把这个问题放在避坑章的最后一个，因为它是程序化交易里最常见的“放大人性追涨杀跌”的算法根源。

6. 让策略跑得更稳的进阶技巧：从日志定位到参数优化闭环

6.1 用结构化日志还原每一次决策

实盘一天下来，交易日志可能有几万行。如果只靠System.out.println输出大括号拼接的字符串，崩溃后你根本找不到线索。平台内置了一套基于Logback的结构化日志，我一般会给策略的输出单独加一个marker：

Logger logger = LoggerFactory.getLogger("STRATEGY"); logger.info(MarkerFactory.getMarker("MA_CROSS"), "signal={}, symbol={}, price={}, pos={}", "BUY", bar.getSymbol(), bar.getClose(), pm.getPosition("rb2410"));

日志出来后，每一行是key=value格式，可以直接用grep和awk做统计分析。排错时最常用的一条命令是：

grep "STRATEGY" logs/quant.log | awk -F ',' '{if($1 ~ /BUY/) print $3}' > buys.txt

这能快速提取出所有买入信号的触发价格。我还会在onBar里把当时的关键指标值一并打出来，比如fastMa和slowMa，这样事后复盘时，不必重新回放就能知道策略在哪个价位、哪个指标状态下做了决定。这就是还原现场的基本功。

6.2 参数敏感性测试的简单做法

参数优化不代表要把策略跑成千上万组参数组合。平台提供了一个ParamSweeper工具，可以在回放模式里批量跑参数网格，并输出“参数-收益-回撤”的二维表。我通常先跑一个粗略网格，比如MA周期从5到60，步长5；再对表现比较好的区间用步长1加密扫描。这样既控制回放时间，又能找到收益面的局部峰值。

跑完参数扫描，我必做的一步是样本外验证。比如用1月到6月数据选参数，然后强制用7月到9月数据做一次回放，如果参数在样本外仍然能盈利才算合格。平台里只需要在yaml里改start和end，不用重启进程。我习惯在优化报告里看到“样本外收益率/样本内收益率”超过0.6才认为这组参数有泛化能力，低于0.3就直接丢弃。

6.3 验证实盘与回放一致性的最后一关

上实盘前，我会先把回放时生成的成交明细导出来，对比实盘模拟盘的成交明细，看两边的“下单时间、价格、手数、手续费”是否匹配。如果出现同样的策略，同一时刻实盘成交价和回放成交价差超过两个最小变动价位，说明回放撮合逻辑和真实撮合有系统性偏差，这种情况下不要急着上实盘，而是回过去检查slip-point设置和tick数据质量。

从那以后，我每次上线新策略都强制走一遍同样的流程：本地回放看收益特征 → 参数敏感性测试找稳定区间 → 模拟盘跑三个交易日 → 导出成交明细做一致性比对 → 实盘先用半自动模式观察一周。这套流程不是平台提供的现成按钮，而是要自己把每个环节的日志和数据都保存下来。它帮我挡掉了至少三次“回测猛如虎、实盘亏成狗”的意外。希望帮到你。

本文还有配套的精品资源，点击获取