回测引擎选择与误差来源

回测引擎不是“软件偏好”，而是研究结论可信度的上限。很多策略在 A 引擎有效、到 B 引擎失效，不一定是策略逻辑变化，更常见是数据处理、撮合规则、费用模型和合约处理口径不同。若不先统一这些口径，比较收益曲线没有意义。

先看三类常见引擎差异。第一类是向量化引擎，例如 vectorbt，优势是速度快、参数搜索效率高，适合在研究早期筛选假设，但对复杂撮合与订单生命周期的刻画相对简化。vectorbt 第二类是轻量事件驱动引擎，例如 backtesting.py 和 backtrader，实现门槛较低，便于把信号、仓位和订单串起来验证。backtesting.py backtrader 第三类是工程化更完整的事件驱动框架，例如 Lean 和 vnpy，更接近实盘结构，适合做研究到部署的一体化迁移。Lean vn.py

误差来源里最常见的是“价格可得性假设”。很多回测默认信号生成时就能按收盘价成交，但真实交易里信号与成交存在时差，且可成交价格受盘口深度影响。这个时差在低频策略里看起来很小，在高波动阶段会被放大成显著偏差。若再叠加盘前盘后或跨市场时段错位，偏差会进一步扩大。交易日历和时段规则应直接参照交易所页面核验，例如 NYSE、Nasdaq、HKEX。

第二类误差来自成本模型。手续费、点差、冲击成本、借贷成本、资金费率和保证金占用，任何一项遗漏都可能把“正收益策略”变成“负收益策略”。加密和期货市场尤其如此，方向判断正确并不保证净收益为正。ccxt、freqtrade 与执行框架的经验都表明，成本建模应进入信号前置过滤，而不是只做复盘解释。CCXT Freqtrade

第三类误差来自数据口径。复权方式、停牌处理、合约换月规则、缺失值填补、时区对齐都会影响结果。尤其是期货与加密衍生品，若忽略主力切换和资金费率，回测会系统性偏乐观。hftbacktest 在盘口级研究中进一步提醒，撮合优先级和排队位置也是收益来源或损耗来源的一部分。hftbacktest

选型原则可以简化为一句话：研究早期优先速度，临近实盘优先真实性。可执行流程是：先用向量化引擎筛假设，再用事件驱动引擎复核执行与成本，最后在接近实盘的环境里做压力测试。每一次迁移都要对比关键指标变化，不只看收益率，还要看回撤、换手、滑点和成交失败率。

一个常见反模式是“为了追求真实而过早复杂化”。研究初期把框架做得太重，通常会降低迭代速度；而长期停留在简化回测又会高估可实现性。平衡点是分层验证：假设验证、执行验证、压力验证分步完成。quantstats 和 pyfolio 可在每一步提供一致的绩效口径，减少“换框架=换结论”的错觉。quantstats pyfolio

回测引擎选择的终极目标，不是得到最好看的曲线，而是得到最接近未来执行现实的误差边界。知道误差边界，才知道该用多大仓位、承受多大波动、在什么条件下暂停策略。

案例复盘

以 2020 年高波动窗口和 2023 年相对稳定窗口做对比，常能看到同一策略在两段时间表现差异显著。若只在稳定窗口优化参数，迁移到高波动窗口会出现滑点和成交失败率突增；若只在高波动窗口校准，又可能错失平稳阶段的效率。正确方式是双窗口并行评估：高波动窗口检验生存能力，平稳窗口检验效率上限。

实施建议

建议建立“引擎一致性报告”：每次模型迭代后，记录向量化回测、事件驱动回测、模拟盘结果在收益、回撤、换手、滑点上的差异。只要差异超阈值，就暂停上线，先定位口径问题。这样可以把误差控制从经验判断转成可审计流程。