企业官网建设流程全解析

1. 量化回测工具选型的底层逻辑

1.1 为什么回测工具的选择比策略本身更致命

很多人一上来就问我“哪个策略能赚钱”，但我干了这么多年量化开发，踩过最大的坑从来不是策略逻辑写错了，而是回测工具选错了导致回测结果和实盘表现差了十万八千里。你用一个滑点模型粗糙、撮合逻辑失真的回测框架跑出来年化50%的曲线，实盘一跑可能连手续费都覆盖不了。所以选回测工具这件事，本质上是在选一套市场仿真引擎，而不是选一个画收益曲线的画图工具。

回测工具的核心价值在于三个层面：第一是数据对齐能力，能不能正确处理不同频率、不同品种、不同时间戳的数据对齐问题；第二是撮合仿真精度，包括滑点模型、手续费计算、成交量限制、涨跌停处理等；第三是策略表达灵活性，你的策略逻辑能不能被这个框架自然表达出来，而不是削足适履。

我见过太多团队在回测阶段花了80%的时间调策略参数，只花20%的时间验证回测框架本身的可靠性。这个比例应该反过来。一个经过严格验证的回测框架，哪怕策略简单一点，至少你知道回测结果和实盘之间的偏差是可预期的。

1.2 回测工具的三条技术路线

目前市面上能用的回测工具，从技术架构上大致分三条路线，每条路线的适用场景和坑点完全不同。

第一条路线是事件驱动型框架，代表就是Backtrader、vn.py、Zipline这些。这类框架的核心机制是模拟真实市场的事件流——行情来了触发on_bar或on_tick回调，策略发出信号后经过风控模块、订单管理模块，最后进入撮合引擎。它的优势是仿真精度高，能处理复杂的订单类型和风控逻辑，适合中低频到中高频的策略开发。缺点是学习曲线陡峭，跑大量参数优化的时候速度慢。

第二条路线是向量化回测框架，代表是VectorBT、pandas自带的rolling计算、以及各种基于numpy的矩阵运算方案。这类框架把整个回测过程转化为矩阵运算，速度极快，适合做大规模参数扫描和因子筛选。但它的致命缺陷是难以处理路径依赖的逻辑——比如移动止损、动态仓位调整、条件单这些，用向量化表达非常别扭甚至不可能。

第三条路线是在线平台型工具，比如聚宽、米筐、优矿这些。它们把数据、计算资源、回测引擎打包成云服务，你只需要写策略逻辑。优势是上手快、数据不用自己维护，适合快速验证想法。但问题是策略容量受限、无法做精细的撮合控制、而且平台迁移成本高——你的策略代码和平台API深度绑定，想换到本地框架得重写一遍。

我的建议是：主力策略用事件驱动框架做精细回测，因子筛选和参数扫描用向量化框架做初筛，在线平台只用来做快速原型验证。三条路线配合使用，而不是只押注一个。

1.3 选型时必须问自己的五个问题

在决定用哪个回测工具之前，我通常会先问自己五个问题，这几个问题的答案基本能锁定工具范围。

你的策略持仓周期是多久？如果是日线级别持仓数天到数周，Backtrader或Zipline足够用；如果是分钟级别甚至tick级别，vn.py或者自己写的C++撮合引擎更合适。你的策略是否涉及多品种套利？如果是，框架必须支持多标的同步回测和跨品种数据对齐。你的策略是否有复杂的订单逻辑？比如冰山订单、条件触发单、OCO订单，这些只有事件驱动框架能处理。你需要跑多少组参数？如果超过一万组，向量化框架的速度优势就体现出来了。你的团队技术栈是什么？Python团队选Backtrader或vn.py，C++团队可以考虑QuickFIX自己搭，Java团队有JQuantLib。

这五个问题没有标准答案，但能帮你快速排除掉不合适的选项。比如你做一个日线级别的多因子选股策略，非要用vn.py就是杀鸡用牛刀，Backtrader或者向量化方案更合适。

2. 主流回测工具深度拆解与实操对比

2.1 Backtrader：最均衡的Python事件驱动框架

Backtrader是我用得最久的回测框架，从2016年到现在，大部分中低频策略的原型验证都是用它完成的。它的设计哲学是“一切皆可扩展”——数据源、指标、订单类型、撮合逻辑、分析器，全部可以通过继承基类来定制。

先看一个最基础的双均线策略回测代码，这是很多人入门Backtrader的第一段代码：

import backtrader as bt class DualMAStrategy(bt.Strategy): params = (('fast', 10), ('slow', 30),) def __init__(self): self.fast_ma = bt.indicators.SMA(self.data.close, period=self.p.fast) self.slow_ma = bt.indicators.SMA(self.data.close, period=self.p.slow) self.crossover = bt.indicators.CrossOver(self.fast_ma, self.slow_ma) def next(self): if not self.position: if self.crossover > 0: self.buy(size=100) elif self.crossover < 0: self.close() cerebro = bt.Cerebro() data = bt.feeds.GenericCSVData(dataname='your_data.csv', dtformat='%Y-%m-%d') cerebro.adddata(data) cerebro.addstrategy(DualMAStrategy) cerebro.broker.setcash(100000) cerebro.broker.setcommission(commission=0.0003) cerebro.addanalyzer(bt.analyzers.SharpeRatio, _name='sharpe') results = cerebro.run()

这段代码看起来简单，但有几个关键细节决定了回测结果的可靠性。setcommission设置的是单边手续费，A股市场还要考虑印花税和过户费，实际应该用bt.CommInfoBase自定义佣金模型。GenericCSVData默认的时间戳处理是逐行读取，如果你的数据有缺失日期，Backtrader不会自动填充，会导致指标计算错位。

Backtrader最大的优势在于它的broker仿真模块。你可以自定义滑点模型，比如固定滑点、百分比滑点、或者基于成交量的动态滑点。我通常会用bt.sizers.PercentSizer来控制仓位，用bt.brokers.BackBroker的set_slippage_perc来设置滑点。对于A股市场，还需要处理涨跌停无法成交的情况，这个需要自己继承BackBroker重写_execute方法。

但Backtrader也有明显的短板。第一是性能瓶颈，纯Python的事件循环在跑tick级别数据时非常慢，一天tick数据大概要跑几分钟。第二是多品种支持较弱，虽然可以添加多个data feed，但跨品种的逻辑处理起来很别扭。第三是社区活跃度下降，原作者已经很久没有更新了，很多新功能需要自己实现。

实操心得：用Backtrader做A股回测时，一定要自己写一个AStockCommission类，把印花税、过户费、最低佣金5元这些规则都加进去。我见过太多人直接用默认的setcommission(0.0003)，回测结果比实盘乐观20%以上。

2.2 vn.py：国内量化圈的事件驱动重器

如果说Backtrader是瑞士军刀，那vn.py就是一把重型工业刀具。vn.py最初是做期货CTA策略的，后来扩展到股票、期权、数字货币等多个市场。它的架构比Backtrader复杂得多，核心模块包括vnpy.trader（交易接口层）、vnpy.app.cta_strategy（CTA策略引擎）、vnpy.app.portfolio_strategy（组合策略引擎）等。

vn.py的回测模块叫BacktestingEngine，它的撮合逻辑比Backtrader更贴近国内市场的实际情况。比如它默认就支持涨跌停板限制、当日平仓限制（期货的平今仓手续费不同）、保证金计算这些国内特有的规则。你不需要像Backtrader那样自己重写broker，vn.py已经帮你处理好了。

用vn.py跑一个CTA策略的回测大概是这样的流程：

from vnpy.app.cta_strategy.backtesting import BacktestingEngine from vnpy.app.cta_strategy.strategies.double_ma_strategy import DoubleMaStrategy engine = BacktestingEngine() engine.set_parameters( vt_symbol="IF888.CFFEX", interval="1m", start=datetime(2020, 1, 1), end=datetime(2021, 12, 31), rate=0.0003, slippage=0.2, size=300, pricetick=0.2, capital=1000000 ) engine.add_strategy(DoubleMaStrategy, {'fast_window': 10, 'slow_window': 30}) engine.load_data() engine.run_backtesting() df = engine.calculate_result() engine.calculate_statistics() engine.show_chart()

vn.py的tick级别回测是它的强项。BacktestingEngine支持tick模式和bar模式两种回测，tick模式下每一笔行情都会触发on_tick回调，撮合精度远高于bar模式。但代价是速度慢——一年的tick数据大概要跑十几分钟，取决于策略复杂度。

vn.py的另一个优势是实盘无缝切换。你写的CTA策略，回测时用BacktestingEngine，实盘时用CtaEngine，策略代码几乎不用改。这个特性对于从回测到实盘的过渡非常友好。但要注意，回测和实盘的撮合逻辑还是有差异的——回测时你的订单是立即成交的（除非你设置了限价单），实盘时可能因为网络延迟、排队顺序等原因无法成交。

vn.py的坑点也不少。第一是版本兼容性，vn.py 2.x和3.x的API差异很大，很多网上的教程代码跑不通。第二是数据格式要求严格，必须用vn.py自己的数据库格式（SQLite或MongoDB），导入外部数据需要写转换脚本。第三是学习曲线陡峭，整个框架的模块划分很细，新手容易迷失在源码里。

注意事项：vn.py的BacktestingEngine默认使用前复权数据，如果你用的是不复权数据，回测结果会有偏差。另外，vn.py的滑点设置是固定值，对于流动性差的品种，实际滑点可能远大于你的设置。建议对流动性差的品种用百分比滑点模型。

2.3 VectorBT：向量化回测的速度之王

VectorBT是我做因子筛选和参数扫描时的首选工具。它的核心思想是用numpy的广播机制和pandas的向量化操作，把整个回测过程压缩成几次矩阵运算。一个包含1000组参数的均线策略回测，VectorBT可能只需要几秒钟，而Backtrader要跑几个小时。

VectorBT的基本用法是这样的：

import vectorbt as vbt import numpy as np price = vbt.YFData.download('AAPL').get('Close') fast_ma = vbt.MA.run(price, [5, 10, 15, 20]) slow_ma = vbt.MA.run(price, [30, 40, 50, 60]) entries = fast_ma.ma_crossed_above(slow_ma) exits = fast_ma.ma_crossed_below(slow_ma) pf = vbt.Portfolio.from_signals( price, entries, exits, init_cash=100000, fees=0.001, slippage=0.001, freq='1D' ) print(pf.total_return())

这段代码同时跑了16组参数组合（4个fast周期×4个slow周期），返回的是一个包含16列收益率的DataFrame。你可以直接用pf.total_return().idxmax()找到最优参数组合。这种速度是事件驱动框架无法比拟的。

但VectorBT的局限性也很明显。第一是无法处理路径依赖逻辑，比如移动止损、动态仓位调整、条件单这些，用向量化表达几乎不可能。第二是内存消耗大，如果你跑1000组参数、每组参数涉及100万条数据，内存很容易爆掉。第三是学习曲线陡峭，VectorBT的API设计很抽象，from_signals、from_orders、from_holding这些方法的参数含义需要花时间理解。

我通常的用法是：先用VectorBT做因子初筛和参数粗扫，找到有潜力的参数区间后，再用Backtrader或vn.py做精细回测。这样既利用了向量化的速度优势，又保证了最终回测的精度。

2.4 在线平台：聚宽、米筐、优矿的快速验证

在线量化平台的最大价值是降低起步门槛。你不用自己搭数据库、不用维护回测引擎、不用处理数据清洗，注册账号就能写策略。聚宽的API设计得比较友好，一个完整的双均线策略大概长这样：

def initialize(context): set_benchmark('000300.XSHG') set_option('use_real_price', True) g.fast = 10 g.slow = 30 def handle_data(context, data): security = '000001.XSHE' close = history(1, '1d', 'close', security)[security] fast_ma = close[-g.fast:].mean() slow_ma = close[-g.slow:].mean() if fast_ma > slow_ma and context.portfolio.positions[security].total_amount == 0: order_value(security, context.portfolio.cash * 0.95) elif fast_ma < slow_ma and context.portfolio.positions[security].total_amount > 0: order_target(security, 0)

聚宽的优势是数据质量高，A股的全历史数据、财务数据、行业分类数据都很全，而且已经做了复权处理。回测速度也还可以，日线级别的策略跑十年数据大概几十秒。但问题在于策略容量受限——聚宽对回测的股票数量、回测时长、并发回测数都有限制，免费账户跑不了太复杂的策略。另外，平台锁定风险很高，你的策略代码和聚宽API深度绑定，想迁移到本地框架得重写。

米筐和优矿的情况类似，各有侧重。米筐的期货数据比较全，优矿的因子库比较丰富。但共同的问题是：你无法控制撮合逻辑的细节，无法做tick级别的精细回测，无法自定义滑点模型。所以在线平台只适合做快速原型验证，不适合做最终的生产级回测。

2.5 自研回测引擎：什么情况下值得投入

我见过不少团队一开始就用Backtrader或vn.py，跑了一段时间后发现框架的某些行为不符合自己的需求，于是开始改源码。改着改着发现改动太大，不如自己写一个。自研回测引擎这件事，我的观点是：除非你有非常特殊的回测需求，否则不要自研。

什么算“非常特殊”？比如你的策略涉及高频做市，需要模拟订单簿的排队和成交，Backtrader和vn.py都做不到这个精度。比如你的策略涉及复杂的跨品种套利，需要同时处理几十个品种的同步回测和保证金计算，现有框架的多品种支持都不够灵活。比如你的策略涉及自定义的订单类型，比如冰山订单、TWAP订单，现有框架不支持。

自研回测引擎的核心模块包括：数据加载模块（处理不同频率、不同格式的数据）、事件循环模块（驱动回测流程）、撮合模块（模拟订单成交）、风控模块（仓位限制、资金管理）、分析模块（计算收益指标）。每个模块都有很多细节要处理，比如数据对齐、时间戳处理、滑点模型、手续费计算、涨跌停处理、除权除息处理等等。

我参与过一个自研回测引擎的项目，团队三个人花了大概四个月才做到能用的程度。这四个月里，大部分时间不是在写代码，而是在验证回测结果的正确性——用已知结果的简单策略去测试引擎，看输出是否符合预期。所以如果你决定自研，一定要预留足够的时间做验证。

3. 回测工具的核心参数配置与实操细节

3.1 滑点模型的设置：回测与实盘偏差的最大来源

滑点是我见过的最容易被忽视、但对回测结果影响最大的参数。很多人回测时把滑点设成0或者一个很小的固定值，结果实盘一跑发现滑点吃掉了大部分利润。滑点的本质是你的订单对市场价格的冲击，以及买卖价差。

滑点模型大致分三种。第一种是固定滑点，比如每笔交易滑点0.01元。这个模型简单，但不真实——流动性好的品种滑点小，流动性差的品种滑点大，固定滑点无法反映这个差异。第二种是百分比滑点，比如成交价的0.1%。这个模型比固定滑点好一些，但仍然没有考虑订单量对滑点的影响。第三种是基于成交量的动态滑点，订单量越大滑点越大，这个模型最真实，但也最难标定。

我在Backtrader里通常这样设置滑点：

cerebro.broker.set_slippage_perc( perc=0.001, slip_open=True, slip_limit=True, slip_match=True, slip_out=False )

slip_open=True表示开盘价也计算滑点，slip_match=True表示如果滑点后的价格超过了当根bar的最高价或最低价，就按最高价或最低价成交。这个设置对A股市场比较合理，因为A股有涨跌停限制，滑点不可能无限大。

对于vn.py，滑点是在set_parameters里设置的：

engine.set_parameters( rate=0.0003, slippage=0.2, ... )

这里的slippage是固定值，单位是价格的最小变动单位。对于IF股指期货，pricetick是0.2，slippage设0.2意味着每笔交易滑一个tick。这个设置对流动性好的品种是合理的，但对流动性差的品种可能偏小。

实操心得：标定滑点最靠谱的方法是用实盘的成交记录反推。把你实盘每笔交易的成交价和当时市场中间价对比，差值就是实际滑点。积累几十笔交易后取平均值，就是比较靠谱的滑点设置。我通常会在这个平均值上再上浮20%，作为回测的滑点参数，留一些安全边际。

3.2 手续费与税费的精确计算

手续费看起来简单，但细节很多。A股的手续费包括佣金（万分之一到万分之三不等，最低5元）、印花税（卖出时千分之一）、过户费（万分之零点二，仅沪市）。期货的手续费分按手数和按成交额两种，还有平今仓和平昨仓的区别。

Backtrader默认的setcommission只支持按比例收费，要处理A股的复杂费率，需要自定义CommInfoBase：

class AStockCommission(bt.CommInfoBase): params = ( ('stocklike', True), ('commtype', bt.CommInfoBase.COMM_PERC), ('percabs', True), ('stamp_duty', 0.001), ('transfer_fee', 0.00002), ('min_comm', 5.0), ) def _getcommission(self, size, price, pseudoexec): comm = abs(size) * price * self.p.commission comm = max(comm, self.p.min_comm) if size < 0: # 卖出 comm += abs(size) * price * self.p.stamp_duty comm += abs(size) * price * self.p.transfer_fee return comm

这个自定义佣金类把佣金、印花税、过户费、最低佣金都考虑进去了。注意pseudoexec参数，它表示这笔佣金是模拟计算还是实际成交时计算，通常不需要区分。

vn.py的手续费设置更贴近国内实际情况。它的rate参数是按成交额的比例，对于期货，你还可以设置size（合约乘数）和pricetick（最小变动价位）。但vn.py默认不区分平今仓和平昨仓的手续费，如果你的策略涉及日内交易，需要自己重写calculate_commission方法。

3.3 数据频率与回测周期的匹配

数据频率的选择直接影响回测结果的可靠性。用日线数据回测一个日内策略，或者用分钟数据回测一个周线策略，都是不合理的。我的经验法则是：回测数据频率至少要比策略持仓周期细一个数量级。

具体来说，如果策略平均持仓周期是5天，用日线数据回测就够了；如果持仓周期是1天，最好用分钟数据回测，因为日线数据无法反映盘中的价格波动；如果持仓周期是几分钟到几小时，必须用tick数据回测。

但数据频率越高，回测速度越慢，数据量也越大。一年的tick数据大概有几十GB，处理起来对内存和CPU都是考验。所以要在精度和速度之间做权衡。我通常的做法是：先用日线数据做初步回测，筛选出有潜力的策略；再用分钟数据做精细回测，验证策略在更细粒度下的表现；最后用tick数据做抽样验证，确认策略在极端行情下的表现。

3.4 回测结果的统计检验

回测跑出来一条漂亮的收益曲线，不代表策略有效。我见过太多过拟合的策略，在历史数据上表现完美，实盘一跑就亏钱。所以回测之后必须做统计检验。

最基本的检验是样本内外分割。把历史数据分成两段，前70%做样本内优化，后30%做样本外验证。如果策略在样本外表现大幅下降，说明过拟合了。更严格的检验是滚动窗口验证，把历史数据分成多个窗口，每个窗口内做优化，然后在下一个窗口验证，看策略表现的稳定性。

另一个重要的检验是蒙特卡洛模拟。把历史交易序列随机打乱，生成多条模拟收益曲线，看实际收益曲线在模拟分布中的位置。如果实际收益曲线在模拟分布的95%分位数以上，说明策略的收益不是随机产生的。

还有一个容易被忽视的检验是参数敏感性分析。如果策略的最优参数是(10, 30)，那么参数在(9, 29)和(11, 31)时表现应该也不会太差。如果参数稍微一变，收益就大幅下降，说明策略对参数过度敏感，实盘中很难稳定盈利。

4. 回测工具常见问题与排查技巧实录

4.1 回测结果与实盘偏差过大的排查思路

回测和实盘偏差大，是最常见也最让人头疼的问题。我通常按以下顺序排查：

第一步，检查数据对齐。回测用的数据时间戳和实盘是否一致？比如回测用的是收盘价，实盘是在收盘前几分钟下单，两者价格可能差很多。检查方法：把回测的成交记录和实盘的成交记录按时间对齐，看同一时刻的价格差异。

第二步，检查滑点和手续费。回测的滑点设置是否合理？手续费是否漏算了某些项目？检查方法：把回测的滑点参数调大，看收益曲线下降多少。如果下降幅度很大，说明滑点是主要偏差来源。

第三步，检查撮合逻辑。回测时订单是否立即成交？实盘时是否有排队延迟？检查方法：在回测中引入订单延迟，比如信号发出后下一根bar才成交，看收益变化。

第四步，检查策略逻辑。回测和实盘的策略代码是否完全一致？有没有因为API差异导致的行为不同？检查方法：用同一段行情数据，分别跑回测和模拟盘，对比信号序列是否一致。

下面这张表是我整理的常见偏差原因和排查方法：

4.2 回测速度优化的几个实用技巧

回测速度慢是事件驱动框架的通病。我总结几个实用的优化技巧：

第一，用numpy数组代替pandas Series。Backtrader的next方法里如果频繁访问pandas Series，速度会很慢。可以提前把数据转成numpy数组，在__init__里计算好指标，next里只做逻辑判断。

第二，减少不必要的指标计算。Backtrader的指标是惰性计算的，但如果你在next里动态创建指标，会导致重复计算。正确的做法是在__init__里一次性创建所有指标。

第三，用多进程做参数优化。Backtrader的cerebro.run支持optreturn参数，可以只返回优化结果而不返回完整策略对象，减少内存占用。配合multiprocessing模块，可以并行跑多组参数。

第四，用向量化框架做初筛。前面说过，VectorBT跑参数扫描比Backtrader快几个数量级。先用VectorBT找到有潜力的参数区间，再用Backtrader做精细回测。

第五，数据预处理。把数据提前加载到内存，避免回测过程中反复读文件。对于tick数据，可以用HDF5或Parquet格式存储，读取速度比CSV快很多。

4.3 回测框架的验证方法

怎么知道你的回测框架是可靠的？我通常用以下几种方法验证：

方法一，用已知结果的策略测试。比如一个简单的“买入并持有”策略，回测结果应该和直接计算买入持有收益一致。如果对不上，说明框架有问题。

方法二，用极端行情测试。比如把某天的数据改成涨停或跌停，看框架是否能正确处理无法成交的情况。如果框架在涨停时还能买入，说明撮合逻辑有问题。

方法三，用不同框架交叉验证。同一个策略，分别用Backtrader和vn.py回测，如果结果差异很大，说明至少有一个框架的设置有问题。我通常会花时间把两个框架的结果对齐，这个过程能发现很多隐藏的坑。

方法四，用模拟盘验证。现在很多券商和期货公司都提供模拟交易环境，用模拟盘跑一段时间，把成交记录和回测记录对比，看偏差是否在可接受范围内。

常见问题：Backtrader回测时，如果数据中有缺失日期，指标计算会出错。解决方法是在数据加载时用bt.feeds.PandasData并确保索引是连续的日期，或者用cerebro.adddata时设置fill_missing=True。

4.4 从回测到实盘的过渡 checklist

回测跑通了，不代表实盘能赚钱。从回测到实盘，我通常会过一遍这个checklist：

• 策略逻辑在回测和实盘中是否完全一致？有没有因为API差异导致的行为不同？
• 滑点和手续费设置是否合理？是否用实盘数据验证过？
• 数据频率是否匹配策略持仓周期？是否用更高频数据验证过？
• 策略是否通过了样本外验证和参数敏感性分析？
• 实盘的资金容量是否足够？策略在多大资金量下会失效？
• 实盘的交易接口是否稳定？有没有处理网络延迟和断线重连？
• 实盘的风控逻辑是否完善？有没有设置最大回撤止损和单日亏损限制？
• 实盘的监控和报警是否到位？策略异常时能否及时发现？

这个checklist看起来简单，但每一条背后都有很多细节。我见过太多团队回测跑得漂亮，实盘一上线就出问题，大部分都是因为checklist里的某一项没做到位。

5. 不同场景下的回测工具组合方案

5.1 股票多因子策略的回测方案

股票多因子策略的特点是标的数量多、调仓频率低、因子计算量大。这种场景下，我推荐的组合是：VectorBT做因子初筛和参数扫描，Backtrader做组合回测，聚宽做快速验证。

具体流程是：先用VectorBT对单个因子做IC分析和分层回测，快速筛选出有效因子。然后把多个因子合成，用VectorBT做参数扫描，找到最优的因子权重和调仓周期。接着用Backtrader做精细回测，加入滑点、手续费、涨跌停限制等约束。最后用聚宽做快速验证，确认策略在不同市场环境下的表现。

这个方案的关键在于因子数据的处理。股票多因子策略涉及大量财务数据和行情数据，数据清洗和对齐的工作量很大。我通常会用pandas做数据预处理，把因子数据整理成DataFrame格式，索引是日期，列是股票代码。然后把这个DataFrame喂给VectorBT或Backtrader。

5.2 期货CTA策略的回测方案

期货CTA策略的特点是标的数量少、调仓频率高、杠杆交易。这种场景下，我推荐的组合是：vn.py做主力回测，Backtrader做辅助验证，自研引擎做高频策略。

vn.py的BacktestingEngine对期货的支持最好，它内置了保证金计算、涨跌停处理、平今仓手续费等国内期货特有的规则。你只需要把期货数据导入vn.py的数据库，设置好合约乘数和保证金率，就能跑回测。

对于高频CTA策略，比如日内tick级别的策略，vn.py的bar模式回测精度不够，需要用tick模式。但tick模式速度很慢，一年的tick数据可能要跑几个小时。这种情况下，可以考虑自研一个简化的tick回测引擎，只处理你需要的品种和逻辑，速度会快很多。

5.3 数字货币策略的回测方案

数字货币市场的特点是7×24小时交易、无涨跌停限制、交易所API差异大。这种场景下，我推荐的组合是：Backtrader或VectorBT做策略原型，自研引擎做实盘对接。

数字货币的回测数据比较容易获取，大部分交易所都提供历史K线数据下载。Backtrader和VectorBT都能处理数字货币数据，但需要注意时间戳的时区问题——数字货币交易所通常用UTC时间，而你的策略逻辑可能基于本地时间。

数字货币的滑点和手续费设置和传统市场不同。数字货币的流动性分化严重，主流币种滑点小，小币种滑点大。手续费通常是按成交额的比例收取，但不同交易所的费率差异很大。回测时需要根据你实际交易的交易所来设置。

5.4 工具组合的迁移成本评估

选择回测工具时，迁移成本是一个容易被忽视但非常重要的因素。如果你用聚宽写了一个策略，想迁移到本地Backtrader，需要重写数据加载、信号生成、订单管理、风控逻辑等模块，工作量可能比重新写一个策略还大。

所以我的建议是：从一开始就选择迁移成本低的工具。Backtrader和vn.py都是本地框架，策略代码可以版本控制，迁移到其他框架或实盘环境相对容易。VectorBT虽然API抽象，但它的核心逻辑是向量化计算，迁移到其他向量化框架也不难。在线平台的迁移成本最高，因为你的策略和平台API深度绑定。

如果你确实需要用在线平台做快速验证，我建议把策略逻辑和平台API分离。比如把信号生成逻辑写成一个独立的函数，输入是行情数据，输出是买卖信号。这个函数可以在任何平台上运行，只需要适配数据加载和订单执行的接口。

6. 回测工具的未来趋势与个人实践体会

6.1 回测工具正在发生的几个变化

这几年回测工具领域有几个明显的变化。第一是向量化框架的崛起，VectorBT、pandas-ta这些库让因子研究和参数扫描的效率提升了一个数量级。第二是云原生回测，越来越多的团队把回测任务部署到云端，用容器化技术做弹性计算。第三是机器学习与回测的融合，用强化学习做策略优化、用深度学习做因子挖掘，这些都需要回测框架提供更灵活的接口。

但无论工具怎么变，回测的核心逻辑没变：用历史数据模拟策略表现，评估策略的盈利能力和风险水平。工具只是手段，关键是你要理解回测的每一个环节，知道哪些地方容易出偏差，知道怎么验证回测结果的可靠性。

6.2 我个人的工具选择建议

如果你刚开始接触量化交易，我建议从Backtrader入手。它的文档比较全，社区虽然不活跃了但历史资料很多，而且它的设计哲学清晰，学懂了Backtrader再学其他框架会容易很多。

如果你主要做国内期货CTA策略，直接上vn.py。它的国内期货支持是最好的，而且实盘对接方便，省去了很多自己搭轮子的时间。

如果你主要做因子研究和参数扫描，VectorBT是必备工具。它的速度优势太明显了，能让你在短时间内测试大量想法。

如果你只是想快速验证一个策略想法，聚宽或米筐的在线平台是最快的选择。注册账号、写几十行代码、点回测，几分钟就能看到结果。

但无论用哪个工具，不要只依赖一个工具。我通常会同时用两到三个工具交叉验证，确保回测结果的可靠性。这个过程虽然麻烦，但能帮你避免很多实盘中的意外。

6.3 一个让我印象深刻的踩坑经历

最后分享一个我早期的踩坑经历。当时我用Backtrader回测一个A股策略，收益曲线非常漂亮，年化30%以上，最大回撤不到10%。我兴奋地把策略上线实盘，结果第一个月就亏了8%。

排查了很久才发现问题出在复权处理上。我回测用的是前复权数据，但实盘交易的是不复权价格。前复权数据把历史价格调整了，导致回测中的买入价格和实盘中的买入价格不一致。更严重的是，前复权数据在除权除息日附近会产生虚假的价格跳空，策略在这些跳空上产生了大量虚假信号。

解决方法是：回测时用不复权数据计算信号，用复权数据计算收益。具体来说，信号生成用不复权价格，因为实盘看到的就是不复权价格；收益计算用复权价格，因为复权价格反映了真实的持有收益。这个细节在Backtrader里需要自己处理，vn.py和聚宽默认已经处理好了。

这个坑让我明白了一个道理：回测的每一个细节都可能成为实盘亏损的原因。滑点、手续费、复权、数据对齐、撮合逻辑，任何一个环节出问题，都可能导致回测和实盘的巨大偏差。所以做回测时，宁可慢一点、细一点，也不要为了追求漂亮的收益曲线而忽视细节。