简介：面向A股量化投资与策略验证的Python开源框架，基于ZipLine进行本地化改造，解决了原版仅适用美股、无法适配A股T+1交易规则和交易时段差异等关键痛点。资源共366个文件，以225个Python源码为核心，包括数据接入、回测引擎、策略模板和可视化模块等；另含Excel数据表、YAML配置、Shell/Bat脚本、IPython Notebook示例等辅助文件，压缩包仅3.42MB，目录设计清晰，便于按需查找学习。框架支持A股历史数据导入、交易费用与滑点模拟，并结合pandas完成数据清洗和指标计算；可视化部分用matplotlib生成收益曲线与交易信号图，同时对分红、配股等A股特有事件做了适配。已有4319人学习使用，通过阅读源码和运行示例，可系统理解从数据接入、策略编写到回测验证的完整流程，为量化研究或二次开发提供可靠参考。 做量化的朋友基本都经历过这个阶段：先在在线平台上把策略逻辑跑通，等到想加自己独有的条件、想接自己的数据源、想看一笔订单为什么被拒的时候，发现平台给你的自由度就那么一点。我是在这个节骨眼上决定自建框架的。翻来覆去比较了一圈，最后选定了Python生态里的Zipline作为底子来改，目标很明确：做一个支持A股的开源量化平台框架。
这篇文章会把整个选型和魔改过程完整复盘一遍，包括为什么选中Zipline而不是其他框架、A股交易规则对回测框架提出了哪些硬性要求、具体改了哪几条主线，以及改造过程中踩过的那些文档里根本不会写的坑。适合正在考虑自建回测系统的量化开发者，也适合对Zipline感兴趣但不知道从哪下手的Python玩家。
1. 为什么绕不开Zipline：一次量化框架选型复盘
1.1 市面框架扫描：各有各的脾气
先说选型。自己做回测平台，通常有四个方向：在线平台、Backtrader、自研引擎、Zipline魔改。
在线平台（聚宽、米筐、掘金这类）的优势是数据和回测体验开箱即用，但策略和数据都被平台绑定，想做平台化、产品化非常困难。Backtrader胜在轻量和社区活跃，中文资料多，可是它更像个“策略编写框架”，数据层、日历层、撮合层之间耦合较紧，做平台化改造时很多扩展点要自己从头设计。自研引擎最灵活，但工作量巨大且容易在细节上翻车。
Zipline是这里面架构完整度最高的。它由Quantopian团队开发，后来开源，核心是事件驱动模型加一套相对清晰的数据门户抽象：DataPortal负责取数，TradingCalendar负责交易日历，Blotter负责订单管理，CommissionModel负责费用计算。这些模块之间的边界比较干净，适合一个团队或一个人在上面做二次开发——这正是我最终选择它的核心理由。
1.2 Zipline的骨架为什么适合“支持A股”这件事
Zipline对A股几乎是“不可用”的，但它的骨架非常适合A股。原因有三点。
第一，事件驱动模型天然贴近A股逐笔撮合逻辑。每天开盘后，直到收盘前，每一笔bar都会触发事件回调，策略可以在bar级别做决策，也可以由调度器在指定时间触发。这种粒度对模拟A股盘中信号很有用。
第二，Pipeline API对全市场选股类策略非常友好。Zipline的Pipeline允许你声明式计算因子，比如“每天取全市场PE排名前30的股票”，框架会自动帮你做数据对齐和重采样，比手动循环遍历股票高效得多。
第三，交易日历和交易时段被抽象成了独立组件。这是最关键的。Zipline默认支持NYSE日历，但它的设计允许你替换成任何交易所的日历。A股和美股在交易时段、节假日上差异巨大，但只要你换掉日历实现，整个回测引擎的时间推进逻辑不用改一行。
1.3 也得接受它的“老毛病”
Zipline不是没有缺点。它最劝退人的地方是文档稀烂、示例少，而且社区维护历经波折——原Quantopian仓库已基本停止更新，现在常用的是Zipline-reloaded分支。我项目里用的就是基于reloaded分支的版本，本质还是Zipline。另外它的依赖体系偏老，Numpy、Pandas版本兼容问题处理起来很烦。不过这些都可以通过固定依赖版本和隔离环境解决，不算致命伤。
选型结论一句话：如果想要一个“骨架完整、可扩展、适合二次开发”的Python开源回测底座，Zipline目前仍是绕不开的最佳选择。它不是最好用的，但它是最好改的。
2. 回测框架必须处理的A股规则差异清单
很多人在自建A股回测时，第一反应是把K线数据和涨跌停加上就完事了。这远远不够。A股和美股在交易制度上的差异是系统性的，任何一个环节漏掉，回测结果都只能当故事看。
2.1 交易日历：不是简单换几个节假日
美股交易日历相对简单，节假日固定。A股日历最麻烦的地方在于调休：春节、国庆这种长假经常有连续休市，而调休上班的周末股市可能不开盘。Zipline默认只有NYSE日历，如果不替换，回测中会把A股休市的日子当成交易日，导致策略在这些天“空转”，订单挂到第二天开盘才成交，收益曲线完全失真。
我当时处理的做法是：从交易所每年发布的休市安排里整理出节假日列表，再转成Zipline的HolidayCalendar和adhoc_holidays。注意这里不仅要加法定假日，还要手工把“周末调休但不开盘”的日子列进去。建议把当年交易所的休市安排整年核对一遍，别只靠常识猜。
2.2 T+1交易制度：回测中最容易被忽略的硬约束
美股允许T+0，当天买入的股票当天可以卖出。A股是T+1，当天买入的股票最早第二天才能卖。Zipline默认的Blotter没有“可用持仓”的概念，它只记录你当前的总持仓，这就导致一个严重的问题：你的策略在回测里当天买入、当天卖出，系统认为没问题，收益算得漂漂亮亮，实盘却根本做不出来。
这个约束必须在订单校验层处理。核心思路是记录“当日买入数量”，卖出时用总持仓减去当日买入量作为可用卖出上限，超过就拒绝订单或缩减数量。听起来简单，但接入Zipline的订单流时有个细节：Zipline的成交回报和订单申请是异步的，校验时要等成交回报更新完持仓后再计算下一个订单，否则会把上一笔未成交的买入也算进去。
2.3 涨跌停与停牌：撮合层必须处理的两个门槛
A股主板涨跌幅限制是±10%，创业板和科创板是±20%，ST股是±5%。涨停时买单排队，可能买不到；跌停时卖单排队，可能卖不掉。如果回测引擎不处理这个约束，策略就能在涨停板上轻松买入、在跌停板上轻松卖出，净值曲线美化得不像话。
处理方式是在撮合前判断订单价格是否超过当日涨跌停价：买单价格高于涨停价，直接撤单或延后；卖单价格低于跌停价，同理。停牌则更直接——当天没有bar数据，任何订单都无法成交。Zipline默认遇到没有数据的资产会直接报错或跳过，这块要改成“停牌期间挂单不成交，恢复交易前自动撤单”的逻辑。
2.4 费用结构：印花税、佣金、过户费一个都不能少
A股交易费用比美股复杂，至少包含三部分：
| 费用项 | 收取方向 | 常见费率 | 说明 |
|---|---|---|---|
| 印花税 | 卖出单边 | 0.05%（当前标准） | 国家收取，费率可能调整 |
| 券商佣金 | 双边收取 | 0.025%左右，最低5元 | 各家券商不同 |
| 过户费 | 双边收取 | 约为成交金额的0.001% | 中国结算收取 |
Zipline内置的默认佣金模型是美股的按每股收费，完全不适用。需要自己继承CommissionModel重写calculate方法，按成交金额算佣金，按卖出方向额外加印花税，同时处理最低佣金5元的问题。滑点模型同理，建议按固定滑点或成交比例滑点处理，默认的VolumeShareSlippage在A股数据上常常失真。
2.5 除权除息与复权处理：很多人踩过的隐形陷阱
A股分红送转频繁，除权除息日价格会跳空下跌，如果不做复权处理，策略会在分红日看到“价格大跌”，误判为亏损信号。Zipline本身有调整（Adjustment）机制，但需要数据源提供分红送转信息，并且在回测时正确应用前复权或后复权价格。
这里要特别提醒一个容易混淆的点：如果用前复权数据做回测，历史价格会被重新计算，而最新价格不变；如果用后复权数据，最新价会大于真实价格，但全序列方向是连续的。我实践中的体会是，做全市场选股策略建议用后复权价格做因子计算，再用不复权价格做成交金额估算，两者配合才能真正贴近真实收益。
3. 魔改Zipline的三条主线：数据、日历与订单逻辑
3.1 数据接入：把A股行情装进Zipline的DataBundle
Zipline原生数据源面向美股，要支持A股，第一件事是替换数据层。常见方案是从Tushare、Baostock、AKShare这类数据源拉取日线行情，然后转成Zipline的DataBundle格式。
DataBundle是Zipline定义的数据集结构，包含OHLCV、资产元数据、调整信息等。你需要写一个数据导入脚本，把CSV或数据库里的原始行情按Assets和BarData的格式写入。日线数据至少要包含open、high、low、close、volume、amount（成交额），如果做因子分析，成交额字段很重要，有些策略里市效率等因子必须用到它。
我当时比较坑的一个点是编码问题：Tushare返回的股票代码格式是“600000.SH”，Zipline资产标识要用整数sid，所以要在导入时维护一张“股票代码与sid映射表”，回测完成后还要再翻译回来。这个小映射看起来简单，但股票数量一多，漏掉退市股就会导致回测期间数据缺失。
3.2 交易日历实现：继承TradingCalendar写一个AShare日历
Zipline的TradingCalendar是一个抽象类，只需要实现几个关键字段。A股日历的核心是open_times、close_times和break_times。A股上午9:30开盘、11:30收盘，下午13:00开盘、15:00收盘，中午11:30到13:00是午休。Zipline原生假设每个交易日是连续的，所以要在日历里定义break时段。
代码骨架大概是这样的：
from datetime import time from zipline.utils.calendars import TradingCalendar from zipline.utils.calendars.trading_calendar import HolidayCalendar, Holiday class AShareTradingCalendar(TradingCalendar): name = "AShare" @property def open_times(self): return ((None, time(9, 30)),) @property def close_times(self): return ((None, time(15, 0)),) @property def breaks(self): return ((None, time(11, 30), time(13, 0)),) @property def regular_holidays(self): return HolidayCalendar([ Holiday("元旦", month=1, day=1), # 春节、清明、五一、端午、中秋、国庆需按年维护 ]) @property def adhoc_holidays(self): # 临时休市，比如交易所通知的额外休市 return []注意regular_holidays只能处理固定日期的节日，春节这种农历节日没法用Holiday直接表达，需要专门按年计算或直接从交易所休市安排表读取。我建议做一个静态表，每年更新一次，远比写一堆农历计算逻辑靠谱。
3.3 订单逻辑调整：T+1校验、涨跌停过滤与佣金重写
这是整个魔改工作中最核心的部分。Zipline的订单流是：策略调用order函数，Blotter生成订单，Broker撮合成交，最后更新Portfolio。我们需要在这个链路里插入A股规则。
T+1校验最简单的方式是在Blotter层维护一个当日买入数量字典，在卖出订单申请时检查：
def validate_order(self, asset, amount): if amount < 0: # 卖出 held = self.portfolio.positions[asset].amount bought_today = self.orders_today.get(asset, 0) available = held - bought_today if abs(amount) > available: return False # 触发T+1限制 return True涨跌停过滤则需要在撮合前计算当日涨跌停价，判断订单价格是否有效。佣金模型重写继承CommissionModel，按3.4小节里的费用表实现即可。
这三个逻辑单独看都不算复杂，真正难的是它们之间的交互——比如一个订单被T+1校验拒绝后又重新提交，或者涨跌停导致部分成交再撤单，这些边界情况需要反复测试。
3.4 Pipeline与数据门户的适配
如果你打算在Zipline上跑全市场选股策略，Pipeline适配绕不开。Zipline的Pipeline要求资产都有一个唯一的sid，并且数据字段要通过DataPortal的load_bars方法访问。A股数据导入后，需要把每股的财务报表、估值因子等写进Pipeline的DataSets。这里我的建议是不要贪多，先把成交量和价格类因子跑通，再逐步扩展基本面因子，否则排查问题时会分不清是数据问题还是撮合问题。
4. 改造中最容易翻车的三个坑
4.1 前复权数据上的“未来函数”假象
这是我踩过最深的坑，没有之一。当时用前复权数据跑一个简单的双均线策略，回测收益好得吓人，年化超过60%。冷静下来一查，发现前复权价格会随最新价格动态变化——今天拉的数据和上周拉的数据，同一个历史日期的收盘价可能完全不同。
这意味着如果每天更新数据后重新回测，历史因子值会被“重写”，回测结果里混进了未来信息，也就是典型的未来函数。排查链路是这样：先打印策略在某个历史日期的因子值，和当时实际行情计算出来的因子值比对，发现不一致，然后追到数据源，确认是前复权导致。
解决办法是改用后复权价格做因子计算和回测，成交金额的估算则用不复权价或当天的成交量乘以成交量加权均价。这个细节直接决定回测结果是否可信，强烈建议每一位改造者提前避开。
4.2 交易日历漏了一个调休日，回测和实盘差出好几个点
这个坑发生在一次长假前，我在日历里漏掉了某个调休日（那天A股实际没有开盘，但我的日历把它当成了交易日）。结果策略在该天照常触发调仓信号，订单被推到下一个交易日开盘才成交。由于下个交易日开盘往往有跳空，买入成本凭空高了一截，回测年化直接掉了几个点。
这类问题排查很隐蔽，因为引擎不报错，只是成交时间错位。后来的解决办法是在回测启动时加了一个“日历-数据一致性校验”：把日历里的每个交易日和数据源里的bar数量逐一比对，凡是日历有而数据没有的日子，要么补数据，要么调整日历。校验通过后再开始回测，能拦截90%以上的日历错误。
4.3 委托价与成交价错位：开盘价还是收盘价
Zipline默认支持在bar的open或close上成交，默认情况是下个bar的open。我一开始图省事，调仓逻辑在收盘时触发，成交价按收盘价算，结果回测净值和实盘差异非常大。原因很简单：A股尾盘有集合竞价，14:57到15:00之间的价格波动和连续竞价不同，收盘价往往不是你能“以收盘价买入”的价格。
解决方式是把调仓触发时间提前到下午14:30之前，用下一根bar的开盘价成交，并叠加合理的滑点。另外，如果做分钟级回测，一定要处理上午和下午两个交易时段之间的价格跳跃，不能把中午休市当成连续行情。
4.4 老Zipline的依赖坑：Python环境隔离是保命符
Zipline-reloaded的依赖版本钉得比较死，Numpy、Pandas、Numba的版本稍有变动就会报错。我最初直接把它装进系统Python环境，结果被其他项目搞得一塌糊涂。后来老老实实建了一个独立虚拟环境，用requirements.txt锁住版本，所有依赖装完后立刻做一次全量回测冒烟测试。如果你刚接触Python生态，安装依赖这一步尤其要重视，一个干净的环境能省下你大量排查时间。
5. 从“能跑”到“跑得准”：回测正确性校验清单
魔改完成后，最怕的就是框架能跑，但结果不对。我整理了一份自测清单，每次改动后都会跑一遍。
5.1 用指数对齐校验日历与价格
第一步用上证指数日线数据做基准回测。写一个最简单的策略：每天全仓买入上证指数ETF（如果有对应的历史数据）或直接买指数本身，期初买入、期末卖出。回测出来的净值曲线必须和真实指数走势基本吻合，如果出现明显偏离，大概率是日历、复权或费用模型有问题。这个测试能快速暴露8成的低级错误。
5.2 构造特殊场景用例逐一验证
针对A股规则，我设计了四个专门的回测用例：
- 某只股票第一天买入100股，第二天尝试卖出200股，应有一半订单被拒。
- 某股票当日涨停，挂买单不应成交。
- 某股票除权除息日，持仓数量应自动调整，净值不应出现不合理的跳变。
- 分红到账后，现金余额应增加，同时持仓成本相应调整。
这四个用例每一个都对应一个常见bug，全部通过才能认为框架的规则执行是对的。我建议你也建一个这样的回归测试集，后续每次改动框架核心代码都跑一遍，比任何代码审查都管用。
5.3 成本敏感性分析：费用模型对策略的影响
相同策略在万分之2.5佣金和千分之一佣金下，收益差距可能会有几个点。所以我在回测报告中固定输出两套成本参数下的净值对比：一套是理想成本，一套是保守成本（佣金万三、印花税0.1%、滑点0.1%）。如果策略对成本非常敏感，说明换手率过高，这种策略在实盘中大概率也难赚钱。这个发现往往会反推你优化策略逻辑，而不仅仅是调框架。
5.4 后续可以扩展的方向
目前这套改造已经可以支撑日线级别的多因子选股、事件驱动类策略回测。再往后走，有三个方向我认为最值得投入：分钟级数据接入和撮合细化、融资融券交易支持、以及通过券商接口做实盘对接。前两个直接决定回测精细度，最后一个决定框架能否闭环。每一步都很费时间，但如果你的目标是做一个真正的量化平台，这些工作绕不开。
最后再分享一点个人体会：改Zipline这件事，技术难点从来不是看懂源码，而是搞清楚每一层抽象后面对应A股市场的哪个真实环节。你每改一个规则，都要先问自己“真实交易中这单子会怎么走”。把这个问题回答清楚了，代码怎么写都是顺理成章的事。我到现在还会时不时翻翻Zipline源码，每次都能发现一些之前没注意到的细节，这也是选成熟开源项目来改的最大红利吧。
本文还有配套的精品资源，点击获取
