从零自研量化回测框架：架构设计与核心模块解析

1. 为什么要自己写一套量化回测框架说实话我最早做量化回测也是backtrader的忠实用户。那阵子它在社区里风头正劲文档齐全、社区活跃策论框架、订单撮合、绩效分析一套流程都有。用着用着问题就来了我需要实现一个比较特殊的组合调仓逻辑基金在T日申购、T1确认份额还带赎回费阶梯backtrader的订单体系不能满足这类需求。我又翻了zipline、qlib的代码发现它们各有各的侧重——zipline做美股事件驱动很顺手qlib是微软开源的AI量化平台CPU利用率和因子研究功能很强。但真要把它们改成适合国内A股、基金、期货的交易规则工作量并不比从零写一个框架小。另一个让我下决心自研框架的原因是“可信度”问题。现成框架像个黑盒子回测出来的净值曲线我不能完全信任。举个例子backtrader在默认情况下处理次日开盘成交时滑点和成交量限制都偏理想化如果你不了解它的撮合细节很容易做出过度乐观的回测结果。而量化交易里最危险的事不是策略亏钱而是回测赚钱、实盘亏钱。如果我自己能完全掌握撮合、手续费、滑点、停牌这些底层逻辑我就能确认每一笔成交都是可信的。所以这一篇先讲清楚一个观点自定义回测框架的核心目标不是取代现成框架而是让你彻底理解回测结果是怎么来的。当你理解了数据流、撮合引擎、账户结算这些基础模块之后再看任何现成框架都会快很多。从系统工程的角度看一个自研回测框架需要做到三点透明每一个成交价、手续费、持仓变动都能追踪到计算来源。可扩展换一个交易品种、加一种订单类型、改一套撮合规则不需要推倒重来。可重现同一份数据、同一个策略、同一组参数任何时间跑都是相同结果。这三点就是你设计模块边界时的指导原则。很多人的第一个版本喜欢把所有逻辑堆在一个类里跑通了再说——我也干过后来发现修改一个撮合细节就要翻几百行代码才意识到模块化的重要性。2. 回测框架的整体架构数据流与模块边界我用了一个最经典的分层架构把回测框架拆成五个模块模块职责输入输出数据层加载、清洗、对齐历史行情原始CSV/数据库数据统一的bar数据结构策略层根据行情信号生成目标持仓bar数据、账户状态目标持仓或订单请求撮合层将订单转换为成交记录订单、下一根bar成交记录、滑点/手续费成本账户层维护资金、持仓、冻结成交记录每日净值、持仓权重分析层计算绩效指标、绘制图表净值曲线、成交记录绩效报告、图表数据流的顺序是数据层 → 策略层 → 撮合层 → 账户层 → 分析层。但有一个关键点值得注意——策略层需要看到账户状态撮合层需要读取下一根bar的OHLCV数据这意味着模块之间其实有交叉依赖。我在设计时用了一个最简单的办法每一根bar推进时由框架主循环按固定顺序调用各模块避免模块之间直接互相调用。伪代码逻辑如下for bar in data_loader: # 1. 先让策略看到当前bar和历史指标 signals strategy.generate_signals(bar) # 2. 将信号转换成订单 orders strategy.signals_to_orders(signals, account) # 3. 撮合所有订单产生成交记录成交价、费用 fills matching_engine.execute_orders(orders, next_bar) # 4. 更新账户持仓、资金、冻结 account.update(fills) # 5. 记录当天净值 equity_curve.append(account.total_equity)为什么不能用简单的“信号→立即成交”模式因为真实市场里你看到收盘价时才产生信号但你的订单最快也只能在下一根bar开盘时成交。如果在同一根bar里既生成信号又立即成交就会引入未来函数——你用到了当前bar的收盘价去成交当前bar的开盘价这在实盘中根本不可能实现。框架主循环的顺序本质上就是在模拟时间不可回溯这一事实。模块之间的数据传递我用的是dataclass这一点后面专门讲。简单说用不可变数据类传递bar、订单、成交记录比传字典清晰得多也不容易误改数据。3. 数据层设计K线数据结构与复权处理数据层是整个框架的地基。如果数据不对后面一切分析都是垃圾进垃圾出。这一节细讲我自己在数据层踩过的坑和最终方案。3.1 数据结构选型回测的bar数据本质上是时间序列的OHLCV开盘、最高、最低、收盘、成交量。选型时有几个选项纯Python对象直观、易调试但性能差几百万条数据会非常慢。pandas DataFrame功能强、生态好但逐行遍历很慢切片和索引也有不少坑比如索引是否唯一、是否排序。numpy结构化数组性能好、内存紧凑但接口偏底层、易读性差。pyarrow Table内存格式高效适合大规模数据但回测逐行操作并不方便。我的最终选择是pandas DataFrame做数据管理层内部转化为list[dict]或numpy数组做策略层的逐bar遍历。数据加载和清洗用pandas因为它的对齐、重采样、缺失值处理太方便了但策略层逐bar遍历时pandas的iterrows()慢得让人抓狂所以先把数据转成numpy数组遍历速度能快几十倍。示例数据加载代码import pandas as pd def load_kline_data(file_path): df pd.read_csv(file_path, parse_dates[datetime]) df df.sort_values(datetime).reset_index(dropTrue) # 统一列名后续所有模块都用这五个标准字段 df df.rename(columns{ open: open, high: high, low: low, close: close, volume: volume })[[datetime, open, high, low, close, volume]] # 转成numpy数组供策略层使用 arr df[[open, high, low, close, volume]].values return arr, df[datetime].values3.2 复权处理的两种思路A股数据天然带除权除息缺口不复权直接回测会出现价格跳空。比如一只股票送股后股价从10元变成5元如果不复权你的策略会被这个假的大跌骗到。复权有两种方式前复权用当前价格倒推历史价格保证最新价是真实价格但历史价格会随每次分红不断变化。同一只股票你今天下载的历史数据和三个月以后下载的历史数据是不一样的。后复权把历史价格按分红送股调整到上市首日基准历史价格是固定的但最新价不是真实交易价格。对回测来说我强烈推荐后复权或等比前复权。很多初学者直接用不复权数据结果回测发现策略在分红日“跳水”然后费半天劲查原因。还有更隐蔽的问题前复权数据更新会导致历史价格变动你在不同时间下载同一段数据回测结果不一样这会让策略研究结果不可复现。实际做法是数据入库时用后复权价格回测时的账户市值再按复权因子换算回真实价格。这听起来复杂但保证了两件事——历史价格固定可复现成交价贴近市场真实水平。3.3 缺失值与停牌处理A股经常有停牌。停牌期间的bar有两种处理方式直接删除这会导致时间序列不连续策略里的滚动指标比如20日均线会算错因为它不知道中间缺了几天。填充为NaN保留日期索引指标计算时跳过NaN这样时间关系是对的。选第二种。具体实现时把停牌日的OHLC全部设为NaN但volume设为0。这样均线类指标在计算时用rolling(window, min_periods1).mean()可以跳过NaN同时成交量0又能帮助你判断“这天不可交易”。数据层还有一个细节复权后的价格可能会出现负值或异常值尤其是送转后。需要在数据清洗阶段加上一个基本检查assert df[close].min() 0, 价格不能为负或零 assert df[volume].min() 0, 成交量不能为负这些assert在数据量大时是必要的防线。量价数据里偶尔会有几行脏数据否则策略会莫名其妙赚一笔不该赚的钱。4. 撮合引擎订单类型、滑点与手续费建模撮合引擎是回测框架里最容易被忽视、却对结果影响最大的部分。很多人写回测时直接用“信号出现 → 按收盘价成交”这个做法在日线策略里可能是可以接受的近似但一旦涉及到开盘价成交、涨跌停不能成交、成交量不足这些细节就会出现严重的失真。4.1 订单类型我的框架最开始只支持两种订单市价单Market Order按下一根bar的开盘价成交。在日线回测里这通常是对“收盘后产生信号、次日开盘执行”的合理模拟。限价单Limit Order指定一个价格只有当下一根bar的最低价低于买入或最高价高于卖出限价时才成交。市价单的成交逻辑是框架里最简单的但也最容易出问题。限制条件是“是否能成交”取决于这跟bar的涨跌停状态——如果这跟bar一字涨停开盘即涨停且封板你的买单根本买不进去。如果忽略这个你的回测里会多出很多不切实际的成交。限价单的成交逻辑稍微复杂一点。比如你挂了一个买入限价单价格是10.0元。下一根bar的最低价是9.9元那你应该在什么价格成交最简单的模型是按10.0元成交你的限价如果按最低价9.9元成交就太乐观了——现实中你限价10元的买单可能在10元附近就被人扫掉很少能刚好抄到最低点。示例撮合代码from dataclasses import dataclass dataclass class Order: order_id: int symbol: str direction: str # buy or sell order_type: str # market or limit quantity: int limit_price: float None filled_price: float None status: str pending dataclass class Fill: order_id: int symbol: str direction: str quantity: int price: float commission: float slippage: float def execute_market_order(order, bar): # bar 是下一根bar的OHLCV open_price bar[open] # 判断涨跌停如果开盘价触及涨跌停且没有成交量默认无法成交 if bar[volume] 0: return None # 无法成交 # 滑点在这里加 fill_price open_price slippage_impact(order.direction, open_price) return Fill( order_idorder.order_id, symbolorder.symbol, directionorder.direction, quantityorder.quantity, pricefill_price, commission0, slippagefill_price - open_price )4.2 滑点模型滑点简单说就是实际成交价和你看的那个价之间的差。在流动性好的股票上可能只有一两个tick但在小市值股票、期货开盘瞬间滑点很可观。滑点建模有三种常见方式固定滑点比如每次成交在信号价基础上加0.02元。最简单适合做低精度验证。比例滑点成交价按价格的万分之一或万分之五偏移。更灵活对不同价格水平的股票都适用。成交量冲击模型根据订单量占当日成交量的比例计算冲击成本。更真实但参数多需要验证。我在框架里的默认设置是固定滑点加比例滑点两者叠加因为实盘中滑点既包含tick价差带来的固定部分也包含流动性不足带来的比例部分。A股回测中我常用“万分之二比例 0.01元固定”这个量级在多数情况下是合理的。4.3 手续费模型手续费是回测里最容易忽视、但最影响长期复利的地方。你如果忽略手续费和印花税一个高频策略在回测里年化50%扣完印花手续费可能只剩30%甚至更低。手续费建模要区分不同市场市场买入费率卖出费率最低收费备注A股股票佣金约万2.5~万3佣金约万2.5~万3 印花税0.05%5元上海市场还有过户费费率极低可忽略ETF佣金约万0.5~万1佣金约万0.5~万10.1元或5元免印花税期货按手数或成交额不同品种差异大同上无还有保证金回测账户层要额外处理我的账户层里手续费直接用函数注入方便切换不同市场规则def commission_cn_stock(direction, quantity, price): amount quantity * price commission max(amount * 0.0003, 5.0) if direction sell: stamp_tax amount * 0.001 # 印花税 else: stamp_tax 0.0 return commission stamp_tax注意两个点一是最低佣金5元小资金账户频繁交易可能大部分利润都交了手续费二是印花税是单边征收卖出才收很多人第一次写会忘。4.4 涨跌停与成交量限制撮合引擎里另一个必备检查是涨跌停限制。A股主板股票当日涨跌幅限制为10%科创板/创业板为20%涨停时买单无法成交因为没人卖给你跌停时卖单无法成交。实现方式def check_price_limit(bar, prev_close, limit_pct0.1): upper_limit prev_close * (1 limit_pct) lower_limit prev_close * (1 - limit_pct) if bar[open] upper_limit - 1e-6: return limit_up elif bar[open] lower_limit 1e-6: return limit_down return normal还有一个细节一字涨停时开盘价等于涨停价且买单堆积、几乎没有卖量。此时如果你的市价买单按开盘价成交回测里能买到但现实中你只能排单等待。我通常的处理是当bar的volume显示为零或极小比如不足日成交量的1%时视为无法成交。5. 策略接口与信号生成保持策略代码干净的关键设计策略层的设计核心目标是让策略作者只关心“怎么产生信号”不关心“订单怎么成交”。这样既便于回测也便于把同一个策略搬到实盘模拟上验证。5.1 策略基类设计我定义了一个很轻量的策略基类from abc import ABC, abstractmethod class Strategy(ABC): name base_strategy def __init__(self, paramsNone): self.params params or {} self.indicators {} self.orders [] abstractmethod def on_bar(self, bar_index, bar, history): 每根bar调用一次策略在这里计算指标、生成目标仓位 pass def buy(self, quantity, order_typemarket, limit_priceNone): self.orders.append(Order( order_idlen(self.orders) 1, symbolself.symbol, directionbuy, order_typeorder_type, quantityquantity, limit_pricelimit_price )) def sell(self, quantity, order_typemarket, limit_priceNone): self.orders.append(Order( order_idlen(self.orders) 1, symbolself.symbol, directionsell, order_typeorder_type, quantityquantity, limit_pricelimit_price ))子类只需要实现on_bar方法。history是框架传入的历史bar数组方便策略计算均线、MACD等指标。5.2 信号生成的两个流派写策略时信号生成有两种风格目标仓位型策略计算出当前应该持仓多少0~100%框架自动下单调整。适合资产配置类策略逻辑清晰风控也容易介入。事件触发型策略在某个条件满足时直接下发买入/卖出指令。适合技术指标类策略比如均线金叉买入、死叉卖出。我推荐在自定义框架里先支持目标仓位型因为它更接近真实账户管理逻辑。你自己管理资金时会思考“我现在应该持有多大的仓位”而不是“我现在要不要买一手”。目标仓位型还有一个好处是天然支持多标的组合你只需要在每个bar结束时告诉框架所有标的的目标权重框架再统一执行调仓。示例策略——双均线目标仓位class DoubleMovingAverageStrategy(Strategy): name double_ma def __init__(self, fast_window5, slow_window20): super().__init__(params{fast_window: fast_window, slow_window: slow_window}) def on_bar(self, bar_index, bar, history): fast_window self.params[fast_window] slow_window self.params[slow_window] close_prices history[close] if len(close_prices) slow_window 1: self.target_position 0.0 return fast_ma close_prices[-fast_window:].mean() slow_ma close_prices[-slow_window:].mean() if fast_ma slow_ma: self.target_position 1.0 # 满仓 else: self.target_position 0.0 # 空仓策略层和撮合层之间的桥接是框架主循环里的一个简单逻辑计算当前持仓和目标仓位的差值再转换成订单。5.3 滑点与手续费对信号生成的影响一个策略在回测中的表现很大程度取决于它“愿意交易多频繁”。如果在设计策略接口时没有考虑交易成本你很容易写出一个在回测里赚很多、实盘里亏光的“高换手策略”。我后面会在实盘那一篇单独讲交易成本的影响。这里只提醒一点策略的调仓频率越高手续费和滑点的影响越大。所以在开发策略时可以在框架里设置一个最低调仓阈值比如目标仓位变化不足5%时不下单这能很有效地过滤掉大量无意义的微调。6. 账户层结算逻辑、保证金与净值计算账户层是回测框架里连接策略和结果的枢纽。它负责记录每一笔成交、更新持仓、计算每天的总资产净值。6.1 基础账户结构用一个简单的账户类from dataclasses import dataclass, field from typing import Dict dataclass class Account: cash: float 100000.0 positions: Dict[str, float] field(default_factorydict) # symbol - quantity cost_basis: Dict[str, float] field(default_factorydict) # symbol - average cost equity_curve: list field(default_factorylist) def update_fill(self, fill: Fill): amount fill.price * fill.quantity if fill.direction buy: self.cash - (amount fill.commission) self.positions[fill.symbol] self.positions.get(fill.symbol, 0.0) fill.quantity # 更新成本基础 old_qty self.positions[fill.symbol] - fill.quantity old_cost self.cost_basis.get(fill.symbol, 0.0) * old_qty new_cost old_cost amount fill.commission if self.positions[fill.symbol] ! 0: self.cost_basis[fill.symbol] new_cost / self.positions[fill.symbol] else: # sell self.cash (amount - fill.commission) self.positions[fill.symbol] self.positions.get(fill.symbol, 0.0) - fill.quantity if abs(self.positions[fill.symbol]) 1e-6: del self.positions[fill.symbol] del self.cost_basis[fill.symbol]这里有个容易踩坑的细节update_fill里处理买入时要先保存旧持仓数量再更新新持仓。如果顺序写反成本基础就算错了。我最初写的时候先更新了持仓再用新持仓算旧成本结果回测净值完全不对查了很久才发现。6.2 持仓市值与净值计算每个bar结束后需要计算账户总资产def update_equity(self, current_prices: Dict[str, float]): total_value self.cash for symbol, qty in self.positions.items(): total_value qty * current_prices[symbol] self.equity_curve.append(total_value) self.daily_return total_value / self.equity_curve[-2] - 1注意这里的current_prices是bar的收盘价不是成交价。账户净值每天按收盘价计算这是行业标准做法。6.3 多标的多空与保证金账户如果策略交易期货或允许做空账户层就需要引入保证金、逐日盯市daily mark-to-market和强制平仓机制。这块逻辑比股票账户复杂不少我在第二版框架里才加入。期货账户的要点开仓时冻结保证金保证金 合约价值 × 保证金比例每日结算价更新浮动盈亏计入账户净值当账户净值低于维持保证金时触发强平如果一开始不用期货把账户层设计成支持“多头/空头”状态即可。我的建议是股票策略先把多头做扎实再考虑融券做空。做空在回测里看着很简单实际执行难度很高A股融券池有限、费率不低、有平仓风险很多“回测赚钱”的空头策略实盘根本做不出来。7. 绩效分析模块收益曲线、最大回撤与稳定性评估回测跑完了净值曲线出来了下一步就是绩效分析。没有绩效分析回测就只是一堆数字不能帮你判断策略是否值得实盘。7.1 核心绩效指标我常用的指标清单如下指标计算方式说明累计收益率净值末尾/净值起点 - 1策略总收益年化收益率(1累计收益)^(252/交易日数) - 1年化视角的收益年化波动率日收益率标准差 × sqrt(252)风险水平夏普比率(年化收益 - 无风险利率) / 年化波动率风险调整后收益最大回撤净值从峰值到谷值的最大跌幅策略最惨时亏多少卡玛比率年化收益 / 最大回撤收益与回撤的关系胜率盈利交易次数 / 总交易次数单笔交易赚钱比例盈亏比平均盈利 / 平均亏损盈利与亏损的倍数关系换手率交易额 / 平均资产策略交易活跃度7.2 最大回撤的计算最大回撤是判断策略风险最直观的指标。计算方式import numpy as np def max_drawdown(equity_curve): equity np.asarray(equity_curve) peak np.maximum.accumulate(equity) drawdown (equity - peak) / peak return drawdown.min()注意最大回撤是按最低点计算的但实际运行中你还要关注回撤的持续时长。一个回撤20%却只持续一周的策略和一个回撤20%持续两年的策略完全是两种风险。所以我在分析模块里还会输出“最长回撤修复时间”。7.3 基准对比与超额收益单看策略自己的净值曲线不够你要和基准比较。A股一般用沪深300指数或中证500指数作基准。比较方式不是把两条曲线画一起就完事而是计算相对强弱策略累计收益 / 基准累计收益Alpha策略扣除市场Beta之后的超额收益信息比率策略相对基准的超额收益与其波动标准差之比这部分的代码可以单独放到perf_report.py文件里用matplotlib绘制净值曲线和回撤曲线。一个经验是绘制净值曲线时用对数坐标因为线性坐标下看长期收益容易忽略早年的波动对数坐标能更公平地展示各时期的收益差异。8. 实战复盘双均线策略从数据到报告理论部分写了这么多来个完整的实操案例。我以A股某ETF的日线数据为例跑一遍双均线策略。8.1 准备数据假设你已经下载了某ETF的日线CSV文件字段包含datetime, open, high, low, close, volume。先用数据层加载arr, dates load_kline_data(etf_daily.csv)8.2 定义策略用前面定义好的DoubleMovingAverageStrategy参数设fast_window5, slow_window20。8.3 配置回测引擎初始化主引擎engine BacktestEngine( dataarr, datesdates, strategy_clsDoubleMovingAverageStrategy, strategy_params{fast_window: 5, slow_window: 20}, initial_cash100000, commission_funccommission_cn_stock, slippage_modelFixedSlippage(0.01), benchmark_databenchmark_arr ) results engine.run()8.4 查看绩效报告跑完后控制台输出累计收益率: 32.5% 年化收益率: 12.8% 最大回撤: 8.7% 夏普比率: 1.21 胜率: 45.2% 盈亏比: 2.3 换手率(年化): 12.6倍这个结果看起来还算能接受。但注意胜率只有45%意味着超过一半的交易是亏损的最终收益靠的是盈亏比来弥补。这种策略在实盘中会带来很多“小亏多次”的心理压力你要先做好心理建设。8.5 参数敏感性分析用双均线策略时一个最先想到的问题是fast_window和slow_window的取值对结果影响大吗我扫描了一组参数fast_windowslow_window年化收益最大回撤夏普比率52012.8%8.7%1.21102010.2%10.1%0.985609.5%12.3%0.8515308.8%9.6%0.92可以明显看到5/20这组参数在这段数据上表现最好但这并不意味着“更好”的参数就是对的。参数搜索里的过拟合风险非常大——你是在用同一段数据“训练”参数再在同一段数据上评估天然会高估策略表现。更严谨的做法是把数据分成样本内和样本外两部分样本内找参数样本外验证。8.6 图表输出用matplotlib绘制净值曲线和回撤import matplotlib.pyplot as plt plt.figure(figsize(12, 8)) plt.subplot(2, 1, 1) plt.plot(results.equity_curve, labelStrategy) plt.plot(benchmark_curve, labelBenchmark) plt.legend() plt.title(Equity Curve) plt.subplot(2, 1, 2) plt.plot(results.drawdown_curve, colorred) plt.title(Drawdown) plt.tight_layout() plt.show()9. 回测框架里最常见的坑与排查经验最后这一部分是我自己写框架以来踩坑经验的总结。这些坑有些来自逻辑错误有些来自对市场规则的忽略有些来自性能瓶颈每一项都值得你在实现时格外留意。9.1 未来函数回测结果虚高的头号元凶回测里最致命的错误就是未来函数。所谓未来函数就是策略用到了当下时点“尚不可知”的信息。最常见的几个来源使用收盘价产生信号却在同一根bar内按收盘价成交正确做法是按次日开盘价成交。计算指标时使用了包含当前bar的数据比如计算5日均线时用到了当前这根bar的收盘价然后立即以当前bar收盘价成交——这在现实中不可能因为收盘价出来时你已经没法以收盘价成交了。数据清洗时不注意对齐比如你用到的复权因子是未来某天才公布的回测时等于“预知”了未来的分红送转信息。排查方法在回测框架里加入一个“延迟成交”模式把信号出现和订单执行严格隔开一根bar看结果差异。如果差异巨大说明你的策略大概率在“作弊”。9.2 撮合顺序错误导致的资金超买框架主循环里如果先撮合买单再撮合卖单或反过来结果可能完全不同。特别是在资金不足时你的买单可能部分成交卖单可能部分成交账户层如果没有正确处理“部分成交”状态就会出现现金为负的诡异情况。我的做法是所有订单先在撮合层统一计算成交结果再按订单ID顺序依次更新账户。这样即使某笔买单因资金不足被拒也不会影响其他订单的撮合。9.3 手续费最低值导致的小资金回测失真commission_cn_stock里最低佣金5元对小资金比如10万以下账户影响很大。如果你初始资金只有1万那每次交易手续费最低5元相当于交易金额的万5年化换手率很高的策略会损失惨重。回测前一定要先算清楚自己的资金规模对应的手续费率。如果资金量小可以在策略里设置“最小交易额”过滤掉太小的调仓否则你会看到一个“因为手续费太贵而亏光”的虚假结论。9.4 性能优化从一小时到三分钟回测框架性能瓶颈主要在三处策略的逐bar遍历如果能用numpy向量化计算指标就别在循环里调pandas函数。数据加载与对齐重复加载同一份数据浪费大量时间用缓存或提前处理好数据格式。撮合引擎的对象创建每次成交都创建好几个dataclass对象如果标的很多、交易很频繁对象创建开销不可忽略。可以对高频路径使用__slots__减少内存占用。我在实测中最大的性能提升来自一个简单改动把numpy的array缓存到策略属性里避免每次循环都重新切片或计算。在一个50万根bar的回测中这个改动让运行时间从50分钟降到8分钟效果非常明显。9.5 与现成框架的关系不要重复造轮子很多人会问我既然有backtrader、qlib这些现成框架为什么还要自己写我的回答是如果只是跑策略用现成框架很合适如果你想深度学习回测的底层逻辑或者想加入现成框架难以支持的特殊交易规则自研框架是值得的。我的路线是先用backtrader跑通一个策略再用自研框架复现同样的结果。当两者输出一致时我对框架的信任度才真正建立起来。这个过程可能会花上几周但它让我的整个研究流程都变得更扎实——我知道每一分收益是怎么来的也知道每一处成本花在了哪里。10. 后续可以怎么扩展这个框架框架跑通之后自然会有很多扩展方向。我自己踩过之后觉得有几个方向性价比很高多标的组合回测把单标的的账户层改成组合账户引入组合权重管理、再平衡逻辑。这比单标的难一些但对资产配置类策略是刚需。事件驱动引擎从逐bar循环改成按事件财报、公告、成交回报驱动这样能更精确地模拟盘口和消息驱动的策略。并行参数扫描写一个参数扫描器用multiprocessing并行跑多组参数效率能提高一个数量级。导入实盘数据把回测框架接到券商或交易所的数据接口上做模拟盘验证。最后再分享一个细节回测框架里所有浮点数比较都要用epsilon容差。比如判断持仓是否为零时用abs(x) 1e-6而不是x 0。很多看似难以理解的bug最后都出在浮点精度上——尤其当交易数量很大时累计误差会越来越明显。我自己实测中就遇到过净值曲线在某一天突然跳变5%最后发现是持仓数量被-1e-15的浮点误差污染导致仓位计算错了。加一个简单的round处理问题就消失了。自研回测框架这件事做了才知道其中的深浅。刚开始你可能会觉得“直接调现成库不香吗”但真正自己写完一整套再去用任何框架都会有一种“一切尽在掌握”的踏实感。这份踏实在实盘交易中比什么策略都值钱。