从零搭建A股量化交易系统：开源框架全流程实战指南

经常有人问我，量化交易是不是必须用商业平台，或者干脆拉一个团队才能搭起来。我的答案一直很直接：不是。一个能跑通“数据—策略—回测—模拟—实盘”全流程的A股量化交易系统，用全开源框架从零搭完全可行，而且我个人认为，亲手搭一遍才是理解量化的最好路径。

这篇文章就写我在自己搭建过程中的完整记录：从数据端 akshare、tushare 怎么选，到回测框架 Backtrader 和 qlib 怎么权衡，再到部署上线时要处理哪些运维问题，以及那些只有真跑起来才会踩到的坑。下面我按搭建顺序一步步说。

如果你是刚开始接触量化的 Python 开发者，或者已经在做数据分析、想往交易方向转的人，这篇文章的价值在于：它把一张系统地图完整铺开，然后告诉你每一步该选哪个开源工具、为什么这么选、实盘上线前要重点检查什么。

1. 框架选型之前，先把系统的边界画清楚

1.1 一套量化交易系统到底由哪些模块组成

很多人上来就写策略，结果写了半年发现连像样点的历史数据都没有。一个完整的A股量化交易系统，不是只写策略就完事。我习惯把整个系统拆成六个模块：

• 数据模块：负责获取、清洗、存储行情、财务、公司公告、板块情绪等数据，是所有环节的输入源头。
• 策略研究模块：在这里做因子分析、回测验证、参数寻优，把交易想法转化成一个能描述“什么时候买、什么时候卖”的规则集合。
• 信号生成模块：在实盘阶段，根据最新数据实时计算持仓目标和买卖信号，需要考虑时效性。
• 执行模块：把信号变成真实委托，处理下单、撤单、改单，并同步订单状态。
• 风控模块：控制仓位、限制亏损、拦截异常订单，是真实资金进场后最重要的保护层。
• 运维与监控模块：保证系统能长期稳定运行，行情断了、磁盘满了、进程挂了都能第一时间发现。

这六个模块不一定要做到同一个进程里。我见过不少新手把数据拉取、策略计算、下单全写在一个脚本里，最后改一个参数都要重新跑全链路，出了问题连定位都难。更好的做法是模块之间解耦：数据层独立出来，策略和风控分离开，执行模块做成可替换的接口。这样做的好处很实在：策略回测失败不影响收盘后的数据更新，执行接口切换券商时也不用动策略代码。

1.2 自建开源系统的真实成本和收益

先说收益。自建的第一好处是策略隐私。在商业平台上写策略，核心代码在别人的服务器上跑，本来就是你我把策略逻辑拱手交给平台。第二个好处是灵活定制，商业平台给什么指标你就用什么指标，自建之后任何数据源、任何频率、任何规则都可以自己接。第三个好处是长期积累，数据清洗脚本、因子库、回测组件都是自己的资产，换平台可以，这些底层能力永远带得走。

再说成本。自建不是零成本，运维时间是最大的开销：数据源接口变了要改，服务器要维护，凌晨行情出问题要爬起来处理。这个成本很多人低估了。另外，商业平台的数据是清洗好的，自建的话你就要自己面对停牌、复权、异常值这些脏数据问题。

所以我的建议是：如果你只是对量化感兴趣、想快速验证思路，直接用商业平台快速起步没问题；但如果你想长期做、打算把策略沉淀成自己的体系，开源自建值得投入。对程序化交易有一定Python基础、愿意花时间折腾的人，走开源路线成长速度会快很多。

1.3 一份可以照着抄的开源工具清单

下面这组选型是我实际用下来最顺手的组合，每一步都是开源方案，单机部署到云服务器就能跑完整个流程。

• 数据获取：akshare（免费、接口全）、tushare（数据质量好、备援用）、baostock（适合做标准历史数据）
• 数据存储：起步用 SQLite，数据量上来后换 PostgreSQL 或 ClickHouse
• 策略研究：Jupyter Notebook 做探索性分析
• 回测框架：Backtrader（事件驱动，逻辑直观）、qlib（微软开源的 AI 量化平台，适合机器学习方向）
• 实盘执行：券商提供的量化接口，或通过 vnpy 对接柜台
• 任务调度：APScheduler，简单可靠
• 部署：Docker + Docker Compose，服务器上一条命令拉起全部服务

这套组合并不是“最新最潮”，但每一层都有大量案例验证过，碰到问题能搜到解决方案，这一点在自建系统时比什么都重要。下面我按从下往上的顺序，把每个环节的选型原因和实操细节展开说。

2. 数据底座：所有策略的起点

2.1 数据源对比：akshare、tushare、baostock 怎么选

数据是量化系统最基础也最容易出问题的部分。我用一张表对比主流的三个开源数据方案。

我现在的方案是：主数据源用 akshare，tushare 做交叉验证，baostock 用来校准历史行情数据。因为 akshare 接口更新速度快，偶尔会有字段变动，所以我在数据层做了一层适配封装，数据源变动时只改封装层，上游的策略代码完全不受影响。

拉取沪深A股日线数据，用 akshare 只需要几行代码：

import akshare as ak # 单只股票的前复权日线 df = ak.stock_zh_a_hist( symbol="000001", # 示例代码，仅用于演示技术流程 period="daily", start_date="20180101", end_date="20231231", adjust="qfq" # 前复权 )

这里有个关键参数：adjust。回测时到底该用前复权、后复权还是不复权，很多人在这里踩坑。我的经验是：做因子研究和策略回测，用后复权数据计算收益率更准确，因为它不会随着最新股价变化而改变历史价格；做技术指标类策略，前复权更贴近看盘软件里的图形。绝对不建议直接用不复权数据做长周期回测，除权缺口会让信号计算出现严重偏差。

2.2 数据落地：SQLite 起步，量大了再换 ClickHouse

数据源拿到的是 DataFrame，但 DataFrame 不能当数据库用。每次启动策略都全量拉一遍数据，既慢又容易被数据源限流。数据要落到本地，增量更新，让策略按日期区间读取。

• 起步阶段用 SQLite：零配置、单文件、Python 内置支持，日线数据跑个几年的量完全够了。
• 数据量到了几千万行、需要高并发读写时，换 PostgreSQL 或 ClickHouse。

我在数据层做了一个简单的表结构，按交易标的和时间索引，行情表和财务表分开：

CREATE TABLE daily_bar ( symbol TEXT NOT NULL, trade_date TEXT NOT NULL, open REAL NOT NULL, high REAL NOT NULL, low REAL NOT NULL, close REAL NOT NULL, volume INTEGER NOT NULL, amount REAL NOT NULL, adjust TEXT NOT NULL, PRIMARY KEY (symbol, trade_date, adjust) );

为什么要用symbol + trade_date + adjust做联合主键？因为同一只股票在同一天存在不同的复权版本，PRIMARY KEY 可以直接防重复写入。配合INSERT OR REPLACE实现幂等写入，脚本重复跑也不会产生脏数据。

增量更新的逻辑很简单：每次写入前查一下表里该标的最新交易日期，只拉这个日期之后的数据。跑完把结果merge进去，然后按主键去重。实际项目里我还加了一步“全量校验”：每个季度抽一批标的，把库里数据和 baostock 历史数据做一次对比，价格偏差超过阈值就触发告警。

2.3 数据质量：复权因子、停牌和异常值处理

数据质量是回测结果可信的前提。三个问题必须处理：

复权数据有一个天然缺陷：每次除权除息后，历史价格会被重新计算。这意味着昨天存进去的前复权数据和今天拉出来的可能不一样。解决方法是每天收盘后统一刷新复权数据，或者干脆用“不复权价格 + 复权因子”的方式自己计算，这样历史序列不会漂移。

停牌日期的处理也很重要。很多新手拿到数据发现 K 线缺了几天，直接用ffill()把缺失日期填满。这样做会让成交量为 0 的停牌日变成“可交易”日。正确做法是：保留缺失日期，在回测里遇到停牌日跳过交易信号。交易时也要提前拉一份停牌列表，防止给停牌股下买单。

异常值我采用“规则 + 人工复核”两道闸：涨跌幅超过 20% 又没有对应公告数据的，标记出来人工看；成交量比过去 60 日均量放大 20 倍以上的，单独归档，不直接删。

3. 策略研究与回测：让想法先被数据检验

3.1 回测框架横向对比：Backtrader、qlib、vnpy 怎么选

回测框架是整个系统里选择最多、争议也最大的部分。我实际用过三个框架，各有特点。

我的选择是：策略研究阶段用 Backtrader，因为它的事件驱动模型非常符合人的直觉，调试方便。等后续要做机器学习因子挖掘时，再接入 qlib 专门负责模型训练和因子分析，把训练好的信号作为因子导入回测流程。这样分工明确，避免一个框架承担所有功能导致哪头都没做好。

3.2 用 Backtrader 写一个完整可运行的双均线策略

一个经典的双均线策略，能完整展示“数据加载—策略定义—回测运行—结果输出”的全流程。下面是可直接运行的代码。

import backtrader as bt import akshare as ak import pandas as pd # 1. 从 akshare 拉数据并转成 Backtrader 需要的格式 def load_data(symbol="000001", start_date="20180101", end_date="20231231"): raw = ak.stock_zh_a_hist( symbol=symbol, period="daily", start_date=start_date, end_date=end_date, adjust="qfq" ) df = raw.rename(columns={ "日期": "date", "开盘": "open", "收盘": "close", "最高": "high", "最低": "low", "成交量": "volume" }) df["date"] = pd.to_datetime(df["date"]) df = df[["date", "open", "high", "low", "close", "volume"]] df.set_index("date", inplace=True) df.index = pd.DatetimeIndex(df.index) return df # 2. 定义策略 class DualMA(bt.Strategy): params = dict(short=5, long=20) # 短期均线和长期均线 def __init__(self): self.sma_short = bt.ind.SMA(self.data.close, period=self.p.short) self.sma_long = bt.ind.SMA(self.data.close, period=self.p.long) self.cross = bt.ind.CrossOver(self.sma_short, self.sma_long) def next(self): # 金叉买入 if self.cross > 0 and self.position.size == 0: self.buy() # 死叉卖出（A股 T+1，当天买入的信号会被下一根K线处理） elif self.cross < 0 and self.position.size > 0: self.close() # 3. 初始化引擎并运行 if __name__ == "__main__": cerebro = bt.Cerebro() data = bt.feeds.PandasData(dataname=load_data()) cerebro.adddata(data) cerebro.addstrategy(DualMA) cerebro.broker.setcash(100000.0) # 初始资金 cerebro.broker.setcommission(commission=0.0003) # 万三佣金 cerebro.addsizer(bt.sizers.PercentSizer, percents=95) # 每次用95%资金 print("初始资金: %.2f" % cerebro.broker.getvalue()) cerebro.run() print("回测结束资金: %.2f" % cerebro.broker.getvalue())

这个代码看起来简单，但有几个细节值得专门说明。self.buy()在 Backtrader 中默认用下一根K线的开盘价成交，这样避免了“用收盘价计算信号、再以当天收盘价成交”的典型未来函数问题。PercentSizer控制每次投入的资金比例，而不是固定股数，更贴近实际资金管理方式。

3.3 回测不能只调参数：手续费、滑点与过拟合

回测框架本身不会替你做对事，参数设置不合理，结果就是看起来很美、实盘亏到哭。我在回测里强制设置了几个成本项：

• 佣金：按实际开户标准设置，我常用万2.5到万3。
• 印花税：卖出时收千分之1，这是固定项，必须算进去。
• 滑点：A股流动性足够的话，我通常按成交价的千分之1到千分之2估算，小盘股会更高。
• 最低佣金：部分券商单笔最低5元，资金量小时这个影响很大。

在 Backtrader 里设置滑点：

cerebro.broker.set_slippage_perc(perc=0.001) # 千分之一滑点

参数调优是过拟合的重灾区。双均线策略里short=5, long=20是一组经典参数，但你用 2018 到 2023 的数据搜索，一定能找到一组让收益曲线更漂亮的参数。问题是这组参数往往是“对着历史答案抄”，换一段样本外数据就失效。我的做法是：参数寻优结果必须做样本外验证和滚动窗口验证，每年重新训练一次，然后跟踪实盘表现是否和回测一致。凡是回测年化收益超过 80% 的策略，我第一反应不是兴奋，而是检查有没有未来函数。

4. 实盘链路：从模拟到真实委托

4.1 实盘接口的四种现实方案

策略在回测里跑得再漂亮，最终还是要面对实盘。A股市场的实盘接入没有期市那么统一，主流的方案有四类：

我的建议很明确：起步阶段不要追求全自动。先把程序生成的交易信号推送给自己，人工核对后下单，跑稳定了再过渡到全自动执行。实盘自动化不只是技术问题，还涉及程序化交易报备、券商审核等合规流程，一定要通过正规渠道向券商申请开通相关权限，按监管要求规范操作。

4.2 风控模块：宁可错过，不可错报

风控是我在实盘中最重视的部分。很多开源框架都有现成的风控组件，但我建议你按自己的资金体量和交易习惯重写一遍，因为默认组件往往不贴合实际需求。我的风控核心规则：

• 单票持仓不超过总资金的 20%，分散到不同行业，单一行业总仓位不超过 40%。
• 单笔亏损达到设定阈值（比如总资金 2%）立即止损，不抱侥幸。
• 日内最大回撤超过 5%，当天停止新开仓，只允许减仓。
• 涨停板不追买，跌停板不抢卖，这类信号大概率成交不了。
• 订单超过 30 秒未成交自动撤单，重新评估后再决定是否下单。

风控模块最重要的一个设计原则是：所有风控检查在下单前做一次、下单后定时复核一次。为什么下单后还要复核？因为实盘中会有行情突变、订单部分成交、接口超时等各种意外，你以为的单子可能根本没有发出去，或者发出去了一部分。不做订单状态同步，很容易出现“账面上有持仓，实际已经平掉”的严重错位。

4.3 从回测到实盘的第一公里

回测跑得很好，不代表实盘能赚钱。我在从回测走向实盘的过程中，按这四步推进：

先用历史数据做样本外验证。拿出一段回测没有用过的数据，比如最近 6 个月，验证策略表现。这个阶段能过滤掉相当一部分“参数恰好拟合历史”的策略。

然后跑模拟盘或纸面交易。让策略信号生成系统运行至少一个月，每天记录信号，人工核对第二天的行情是否验证了信号的有效性。这一步重点检验的不是收益率，而是信号生成是否稳定、数据链路是否可靠。

接着用小资金实盘。我建议用总计划资金的 5% 到 10% 起步，跑至少两到三个月。这个阶段要重点关注实盘成交价和回测理论价之间的差距，也就是滑点损耗。

最后逐步放量。每轮放量后都要复盘执行误差，确认系统处理大资金的容量没问题，再进入下一轮。

5. 部署上线与日常运维

5.1 一台服务器和一套 Docker 编排就够了

很多人的量化系统一直跑在自己的笔记本上，这是最大的隐患。笔记本一休眠，数据更新、信号生成全部中断。我建议直接用一台云服务器，配置不用太高，4核8G的入门配置足够跑日线级别的全市场扫描。

部署我统一用 Docker Compose 编排，好处是环境一致、迁移方便。下面是一个简化的编排文件：

version: "3.8" services: db: image: postgres:15 environment: POSTGRES_DB: quant POSTGRES_USER: quant POSTGRES_PASSWORD: change_me volumes: - ./pgdata:/var/lib/postgresql/data restart: unless-stopped collector: build: ./services/collector depends_on: - db restart: unless-stopped volumes: - ./logs:/var/log/quant trader: build: ./services/trader depends_on: - db restart: unless-stopped volumes: - ./logs:/var/log/quant

这个编排把数据库、数据采集、交易服务拆成三个独立容器。restart: unless-stopped保证进程意外退出后自动拉起，日志统一挂载到宿主机目录，方便排障。实际部署时还需要处理配置文件、密钥管理等问题，不要把券商账号密码直接写在环境变量里，至少用一个.env文件并设置好权限。

5.2 定时任务不是“每天0点跑一次”

量化系统的调度最容易忽略的问题，就是交易日历。很多新手用cron写一个“每天执行”，结果碰上节假日白白跑一趟，更麻烦的是法定节假日调休——周六要补班但股市不开盘，周日休息但有的行业公司要上班。正确做法是维护一份交易所交易日历，底部数据源直接获取全年交易日：

import akshare as ak df = ak.tool_trade_date_hist_sina() df.to_csv("trade_calendar.csv", index=False)

调度框架我用 APScheduler，它支持 CronTrigger，可以直接按交易日和具体时间触发。一个简单的每日任务这样写：

from apscheduler.schedulers.blocking import BlockingScheduler from apscheduler.triggers.cron import CronTrigger def update_daily(): update_daily_bar() update_financial_data() generate_signals() if __name__ == "__main__": sched = BlockingScheduler() # 周一至周五，收盘后30分钟执行 sched.add_job(update_daily, CronTrigger(day_of_week="mon-fri", hour=16, minute=30)) sched.start()

注意任务执行时间要避开数据源高峰。A股 15:00 收盘后，数据源接口通常还在更新数据，我一般安排 16:30 之后跑数据更新，17:30 跑策略信号计算，第二天开盘前再跑一次开盘前检查，确认数据新鲜度和昨日订单状态都正常。

5.3 监控告警做到位，周末才能睡得着

系统部署上线后，运维的核心就一个字：稳。我的监控分三层：

第一层是进程监控。Docker 容器挂掉了要能自动重启，同时发通知给自己。第二层是数据监控。每天检查数据更新是否按时完成、最新交易日是否有数据、字段是否有异常。第三层是交易监控。实盘运行时，订单状态异常、资金变动异常、连续信号反复变化都要告警。

告警渠道我用的是企业微信机器人好还是钉钉机器人或者邮件，都可以，关键是消息要能第一时间到手机上。我习惯把告警分级：数据延迟是警告级，可以当晚处理；进程挂掉是紧急级，需要立刻处理；实盘订单失败是最高级别，直接打电话通知。

这里分享一个教训：我早期把所有日志都打到标准输出，容器一重启就什么都查不到。后来把所有服务日志统一收集到宿主机目录，按天切分，至少保留 30 天。排查历史问题的时候，能还原当时的买卖决策和状态记录，比什么都重要。

6. 真实踩坑记录：数据、回测、实盘三个层面的问题

6.1 数据坑：复权因子变化和停牌缺失

数据层的坑最隐蔽，出了问题也最难发现。第一个坑是前复权数据漂移。今天拉下来的历史价格，和一个月前拉的同一天价格不一样，因为前复权会随最新价重新计算。这直接导致回测结果无法复现，策略回测报告今天跑出来和明天跑出来不一样。解决方法是改为使用后复权数据，或自己保存复权因子。

第二个坑是停牌数据的处理。停牌期间没有成交，有些数据源会直接缺失该交易日记录，有些会给出成交量为 0 的记录。如果不统一处理，回测中信号计算会因为缺失而跳变，实盘中就会出现给停牌股下委托的乌龙。我现在的做法是：合并交易日历，缺失日期补录为“停牌状态”，交易逻辑里遇到这个状态直接跳过。

第三个坑是财务数据和股价数据不同步。财报发布日期和市场预期日期之间有滞后，很多人拿到财报数据就直接和当天的股价对齐，这是用到了未来数据。财务数据必须用“公告日期”去关联，而不是“报告期”。

6.2 回测坑：T+1 和未来函数

回测阶段最典型的未来函数，是在当天收盘价计算信号后又用当天成交去验证收益。Backtrader 默认使用下一根K线开盘价成交，已经规避了大部分问题，但如果你自己写回测逻辑，一定要确认信号计算时间和成交时间有一个时间差。

A股特有的 T+1 规则也是回测中容易漏掉的。当天买入的股票，无论信号怎么变化，当天都不能卖出。很多开源框架按美股习惯设计，默认允许日内买卖。我一开始用 Backtrader 跑策略，回测结果出来后收益率很夸张，后来才发现日内买进卖出被模拟器当成可行交易了。修正方法是用一个持仓日期变量记录买入日，只有当当前日期 > 买入日期时才允许卖出。

还有一个普遍存在但很难察觉的坑是幸存者偏差。如果回测股票池用的是“当前还在上市的股票集合”，那退市的、业绩暴雷的股票全被剔除了，回测结果天然偏高。正确做法是使用历史某一时点的全部股票集合，包括后来退市的，这需要数据层保存股票上市状态的历史信息。

6.3 实盘坑：开盘买不进、撤单失败、断线重连

实盘的坑比回测更疼，因为每一条都涉及真实资金。第一个坑是开盘瞬间买不进。很多策略信号是在开盘集合竞价后产生，但开盘头几分钟流动性最差，特别是小盘股，买单发出去可能只有部分成交甚至完全不成交。我现在的处理是：信号产生后不着急用市价单，先发限价单，设置一个合理价位（比如昨日收盘价加减一定幅度），30 秒不成交就撤单重发。

第二个坑是撤单失败。券商接口的撤单请求偶尔会超时，看似没有回报，但实际上委托已经撤销或者已经成交。这时候如果直接重新下单，可能会重复建仓。解决方法是：撤单请求发出后，主动查询委托状态，确认“已撤”或“已成”后再走下一步流程。

第三个坑是断线重连。实盘交易时段内行情通道和交易通道都可能断线，如果程序没有自动重连机制，信号堆积到恢复后一次性执行，等于完全脱离风控。我的方案是单独盯行情心跳，断线超过一段时间就强制把策略切到“只读模式”，只出信号、不下单，等链路完全恢复后人工确认再放开。

实盘系统里，无论行情还是交易接口，都要做幂等控制。我习惯给每一笔委托生成唯一订单号，重复请求时券商端已经存在的单子就不会重复报。配合日志审计，出了纠纷至少能还原过程，这既是技术保障，也是一种基本的交易行为规范。

最后再说几句

从零搭一套A股量化交易系统，技术上并没有想象中那么难，真正难的是把每个环节的细节处理好，让系统在没人盯着的时候也能稳定运行。我自己在这个项目上最大的体会是：不要追求一步到位，先跑通最小闭环，再逐步迭代。

如果你刚开始动手，我建议路线是这样的：先把数据底座建好，用 1 到 2 周时间把 akshare 的日线、财务、交易日历全部落库，然后把一个简单策略在 Backtrader 里跑通，接着接模拟盘跑一个月，最后才考虑实盘。每一步踩过的坑都会变成你自己判断策略和系统的直觉，这是任何商业平台的现成功能都给不了你的东西。

等到核心链路稳定之后，还可以往两个方向扩展：一个是在回测端接入 qlib，利用它的机器学习流水线做因子挖掘和模型选股；另一个是对公告、研报这类文本数据做本地化的语义分析，现在轻量级的本地大模型推理方案已经可以在普通服务器上跑起来了，用来做盘前的舆情辅助分析很实用。不过这些都是后话，先把数据和回测的基础打牢，后面加什么模块都会很顺手。