简介这是一份以Python为核心的量化交易PAAS平台源码面向量化开发者与金融IT人员解决策略研究、回测、模拟交易到实盘执行的工程化落地问题。代码库由590个文件构成包括170个Python模块、134个Rust组件、40项YAML参数配置、30个Shell自动化脚本及dockerfile、Markdown文档等压缩包约4.19MB目录按模块化架构组织便于二次开发。平台整合了分布式任务调度、金融数据管理、多策略历史回测、交易模拟测试及可视化分析等完整工作流支持本地私有化部署可适配证券市场、期货市场及自定义金融产品。目前已有67人学习下载适合需要搭建量化投研平台的团队或个人参考尤其对Rust与Python混编、任务编排等实现具有直接借鉴价值。1. 这不是一个回测脚本而是一套量化PaaS的骨架做了几年量化交易你一定经历过这种痛策略代码在 Jupyter 里跑得有模有样换到定时任务就各种崩回测用的行情接口和实盘接口对不上多策略想并行评估得自己折腾进程池和锁。这套源码的核心价值是把这些散落在各处的工程问题做了一层收敛——它用 Python 组织任务流用 Rust 承担计算热点用 YAML 管理策略参数再加上分布式调度和本地化部署形成了一套完整的多策略回测与交易执行框架。项目由 480 份文件组成其中 170 个 Python 模块、134 段 Rust 组件、40 份 YAML 配置包含从数据管理、历史回测、模拟交易到实盘执行的完整链路。适合两类人一是想快速搭建自有量化平台、不愿从零写撮合和风控的团队二是正在研究 Python 与高性能语言混合编程的开发者。2. 任务编排与分布式调度从启动脚本到任务分发的落地路径量化平台里耗时最长的不是策略本身而是数据检查和任务编排。你会看到项目根目录下放着start.bat、glances.conf、pip.conf这些容易被忽略的文件它们分别解决启动引导、资源监控和依赖安装这三个基础问题。下面按实际使用顺序拆开讲。2.1 start.bat 启动流程与依赖环境准备Windows 环境下的启动脚本通常承担两层责任检查 Python 环境、按顺序拉起各个服务。典型的start.bat长这样echo off setlocal enableextensions set PYTHON_CMDpython set BASE_DIR%~dp0 set LOG_DIR%BASE_DIR%logs if not exist %LOG_DIR% mkdir %LOG_DIR% %PYTHON_CMD% -c import numpy, pandas, yaml 2nul if errorlevel 1 ( echo [ERROR] Missing dependencies, running pip install... pip install -r requirements.txt ) %PYTHON_CMD% -m app.scheduler --config config/scheduler.yaml %LOG_DIR%\scheduler.log 21 %PYTHON_CMD% -m app.backtest --config config/backtest.yaml %LOG_DIR%\backtest.log 21这里先用python -c import ...做依赖探测缺包时自动走pip install避免每次启动都重新解析全部依赖。后台任务用 log 21把日志重定向到独立文件防止一个服务崩溃把整个控制台输出冲掉。%BASE_DIR%确保了脚本在任意目录下双击都能定位到项目根。关键区别在于不要把start.bat当成一次性启动工具它本质上是任务编排的入口。调度服务、回测服务、API 服务可以分开启动也可以按依赖顺序合并启动。下面这张表是启动脚本里最常出现的配置项配置项作用常见值PYTHON_CMD指定解释器路径python或/opt/venv/bin/pythonBASE_DIR项目根目录%~dp0Windows或$(pwd)LOG_DIR日志输出目录./logs--config指向 YAML 任务配置config/*.yaml21合并标准错误与标准输出固定写法在多机部署场景里这种批处理脚本会被 systemd 或 supervisor 替代但核心逻辑相同先探活、再启动、最后落日志。2.2 任务队列与分布式调度器的选型这套平台的任务调度层没有盲目引入 heavyweight 框架而是用 Python 写了一个基于队列的任务分发模块。常见做法是在app.scheduler里把任务拆成「定时触发」和「事件触发」两类。定时任务用APScheduler维护 Cron 表达式事件触发任务则走Redis队列。下面是一个简化版调度器代码# app/scheduler/dispatcher.py import json import redis from apscheduler.schedulers.background import BackgroundScheduler class TaskDispatcher: def __init__(self, redis_urlredis://localhost:6379/0): self.redis redis.from_url(redis_url) self.scheduler BackgroundScheduler(timezoneAsia/Shanghai) def register(self, task_name, task_func, cron_expr): 注册一个可调度的回测或数据任务 self.scheduler.add_job( funclambda: self._push(task_name, task_func()), triggercron, **self._parse_cron(cron_expr) ) def _push(self, task_name, payload): self.redis.rpush( quant:tasks, json.dumps({task: task_name, payload: payload}) ) def _parse_cron(self, expr): # 0 2 * * * - {hour: 2, minute: 0} parts expr.split() return {minute: parts[0], hour: parts[1]}register方法用 Cron 表达式描述任务触发时机_push把任务序列化后塞进 Redis 列表。分布式中的 worker 进程只需lpop这个队列就能做到多机消费。这种设计的好处是调度器和执行器完全解耦扩容时只需要加 worker不需要改调度逻辑。注意_parse_cron需要对秒级任务做额外控制默认场景下分钟级就够。相比直接上 Celery这种轻模式适合任务数少于 200 个、且不需要复杂路由的团队。项目里的 40 份 YAML 配置一部分就是在描述这些任务的 Cron 表达式和参数入口后面会详细展开。2.3 多机部署时的资源管理与监控配置分布式起来之后最先暴露的问题不是任务跑不完而是某台机器 CPU 被打满却不知道是哪个 worker 干的。仓库里的glances.conf就是用来统一监控多机性能的。Glances 本身是个 Python 写的跨平台监控工具glances.conf可以配置 Web 端口、刷新间隔和客户端模式[global] refresh2 check_updatefalse [web] bind0.0.0.0 port61209 [client] server192.168.1.10 port61209scheduler节点负责采集client节点从中央服务器拉数据。这样你在控制台上能看到每一台 worker 的 CPU、内存和进程状态。配合pip.conf配置内网 PyPI 镜像新机器入职后的初始化时间能压缩到两分钟以内[global] index-url http://mirrors.internal.team/simple/ trusted-host mirrors.internal.teamtrusted-host必须显式声明否则从 HTTP 源装包会被 pip 拒绝。团队内部部署时建议把requirements.txt里的版本全部 pin 死避免新机器装到不同版本导致调度结果不一致。3. 多策略回测与数据管理参数配置层与 Rust 模块的配合回测系统最容易踩的坑是「策略逻辑和数据接口纠缠在一起」。这套平台把回测拆成了策略定义、行情加载、收益计算三块其中收益计算层大量使用 Rust 组件后面详说。3.1 策略模块的输入输出与参数化约定每个策略在 Python 层都是一个类继承同一个BaseStrategy抽象类必须实现initialize和next两个方法。这样设计的目的很明确回测引擎只认这个接口策略内部怎么调仓是开发者的自由。# app/strategies/base.py class BaseStrategy: def __init__(self, params: dict): self.params params self.position 0 self.cash params.get(initial_cash, 1_000_000) def initialize(self, context): 初始化指标、缓存、连接等 ... def next(self, context): 每个bar触发一次 ... def on_data(self, bar): 回测引擎回调入口 signals self.next(self.context) return self._validate_signals(signals) def _validate_signals(self, signals): 只接受 buy sell hold 三个选项 allowed {buy, sell, hold} if not all(s in allowed for s in signals): raise ValueError(finvalid signal: {signals}) return signalssell信号这里不做数量控制的话实盘会出问题——引擎层会把整个仓位一次卖出而_validate_signals只做合法性检查。回测参数通过params字典传入比如移动平均线的窗口要同时写在策略初始化和 YAML 配置里两边一旦不对齐结果会非常诡异。3.2 YAML 配置层多策略参数如何组织项目里 40 份 YAML 文件接近一半是策略配置。拿双均线策略举例# config/strategies/ma_cross.yaml strategy: name: ma_cross_5_20 module: strategies.ma_cross params: fast_window: 5 slow_window: 20 initial_cash: 1000000 max_positions: 3 data: source: local_parquet symbols: - 000300.SH - rb888.SHF start_date: 2020-01-01 end_date: 2024-12-31 interval: 1d推荐在 YAML 里写max_positions而不是策略代码里写死这样同一份策略可以配置出不同版本做参数扫描时只需要遍历 YAML 文件。回测引擎读这个文件时会先把module字符串解析成类名再实例化并注入params。这里有个约定所有文件里的日期统一用字符串解析时再转datetime否则 YAML 会把2020-01-01解析成datetime.date对象JSON 序列化时容易出错。多策略回测的另一个关键是行情数据本地化。项目支持本地 Parquet 目录作为数据源目录结构一般按symbol/interval/year.parquet组织。回测时只加载配置中symbols指定的文件避免读全市场。表结构类似字段类型说明datetimedatetime64[ns]时间戳需要设置索引open/high/low/closefloat64OHLC 价格volumeint64成交量amountfloat64成交额价值型策略用到open_interestint64期货持仓量股票标的可以填 0加载这种数据时最常遇到的坑是时间戳时区。如果你下载的是带08:00的数据回测引擎会按 UTC 再转一次直接导致 K 线错位。建议在数据落地时就统一成Asia/Shanghai的 naive 时间不要带时区后缀。3.3 Rust 组件如何加速回测计算项目包含 134 段 Rust 组件这些不是摆设。回测里的收益计算、撮合撮合结果汇总Python 处理百万级 bar 会非常吃力Rust 正好承担这部分数值计算。常见做法是用 PyO3 把 Rust 代码编译成 Python 可以 import 的扩展模块示意代码// backtest_engine/src/portfolio.rs use pyo3::prelude::*; #[pyfunction] fn calculate_equity_curve(returns: Vecf64, initial_cash: f64) - Vecf64 { let mut equity Vec::with_capacity(returns.len()); let mut current initial_cash; for r in returns { current * 1.0 r; equity.push(current); } equity } #[pymodule] fn backtest_engine(m: Bound_, PyModule) - PyResult() { m.add_function(wrap_pyfunction!(calculate_equity_curve, m)?)?; Ok(()) }编译好后Python 侧是这样调用的import backtest_engine raw_returns [0.01, -0.02, 0.03] equity backtest_engine.calculate_equity_curve(raw_returns, 1_000_000) print(equity) # [1010000.0, 989800.0, 1019494.0]这里传入的raw_returns是策略next方法算出来的日收益率序列。Rust 侧用Vecf64接收然后逐项累乘。注意它的后缀是f64而 Python 的float精度更低传输大批量数据时会有类型转换开销。如果数据量超过 100 万条建议用 NumPy 数组零拷贝传给 Rust不要用 list。混合编程最容易忽视的是构建链。start.bat启动前必须保证.so或.pyd文件存在否则 import 直接失败。排查顺序先确认 Rust 版本与 Python 版本匹配再确认 PyO3 的abi3特性是否启用。abi3可以让我编译出的扩展同时兼容 Python 3.8–3.12省掉多版本编译成本。4. 实盘交易与模拟撮合从回测到执行的边界控制回测能跑通只是第一步真正决定这套平台能不能用于生产的是回测策略与实盘交易所之间的接口设计。这个项目的模拟撮合和实盘交易共用一个执行接口切换成本被压到最低。4.1 统一的订单执行接口接口层定义如下# app/brokers/base.py class BaseBroker: def connect(self, account_id: str): ... def place_order(self, symbol: str, side: str, quantity: float, order_type: str market): side 只允许 buy 或 sell ... def cancel_order(self, order_id: str): ... def get_position(self, symbol: str) - dict: 返回 {symbol: str, qty: float, avg_price: float} ...回测时用的SimulationBroker会先走一遍撮合逻辑再返回成交回报实盘时LiveBroker内部把同样的订单结构转换成券商或期货公司的 API 请求。这样策略层不需要关心资金账户细节只管发单和监听回报。这里需要你注意一个边界回测环境里订单是即时成交的实盘里可能挂单半天不动。所以策略发出sell信号后平台会先查get_position()如果返回None就丢弃这次信号并记录日志。这个保护逻辑写在执行器里不写在策略里保证上实盘时不会因为异步延迟产生「裸卖空」。4.2 模拟撮合与滑点模型模拟撮合最有价值的点是滑点模型。许多回测平台把滑点设为一个固定百分比例如0.1%这在波动率大的标的上误差非常大。这个项目支持两种滑点按固定价位、按盘口深度估算。下面是一个撮合器核心逻辑# app/execution/matching.py def execute(bar, order, slippage_modefixed, slippage_value0.02): bar 是一个字典包含 open/high/low/close/volume 返回成交价和成交量 if order[side] buy: fill_price bar[open] * (1 slippage_value) if slippage_mode fixed else min(bar[high], bar[open] slippage_value) fill_qty order[quantity] else: fill_price bar[open] * (1 - slippage_value) if slippage_mode fixed else max(bar[low], bar[open] - slippage_value) fill_qty order[quantity] return {price: round(fill_price, 6), quantity: fill_qty}slippage_modefixed适合股票slippage_value0.02表示下单价格上浮 2 个基点。注意这里用的是bar[open]因为分钟级别的回测中bar 收盘后你才知道信号下单时最合理的参考价是下一根 K 线的 open。很多刚上手的人在这点犯错误用当前 bar 的 close 成交然后发现回测收益高得离谱——那是未来函数。如果你使用盘口模式需要传入一个订单簿深度数据源而且slippage_value的含义会变成「最多容忍滑 2 个 tick」代码逻辑要按bar[high]和bar[low]做边界限制。两种模型在合成数据上差异不大但在真实盘中盘口模式的成交回报会分散到每笔价格区间导致持仓成本分配更复杂。4.3 持仓、风控与撤单重启执行层还有一个容易被忽视的问题进程重启后本地记录的手数还准不准。平台的持仓管理模块支持从 broker 拉取真实仓位做本地重建而不是单纯依赖内存字典。风控规则表也放在配置里# config/risk/limits.yaml risk: max_position_ratio: 0.6 max_single_order_value: 200000 max_daily_loss: 50000 allow_short: false close_on_signal_end: truemax_daily_loss是每日最大回撤限额达到后执行器所有新订单都会被拒掉。allow_short默认关闭防止股票策略误开空头。这些规则是在BaseBroker.place_order之前拦截的属于前置风控此外平台还支持撤单重启恢复启动时读取本地order_history.json把未完成订单标记为canceled避免重复挂单。5. 私有化部署的最终检查监控、依赖与启动排错这里不谈概念只讲把平台真正跑起来时最容易卡住的三件事。第一是glances.conf的 Web 端口在云主机上用不了——因为默认绑定了0.0.0.0但安全组规则没放行 61209 端口你会一直在容错期间绕墙。确认监听用ss -lntp | grep 61209如果你是在本机调试把bind改成127.0.0.1是更稳的选项。第二是pip.conf与requirements.txt的配合。仓库里放了一个pip.conf模板但在有内外网隔离的机构里它必须放在%APPDATA%\pip\pip.iniWindows或~/.pip/pip.confLinux才会生效。启动报ModuleNotFoundError: No module named numpy时先看是不是pip.conf指向的镜像源缺包再考虑是不是 Python 版本不兼容。项目大量使用 Rust 组件旧版本 Python 3.7 会被 PyO3 的编译产物拒之门外推荐直接用 Python 3.10 或 3.11。第三是start.bat启动后进程秒退。常见原因不是脚本里有语法错误而是%PYTHON_CMD%指向的 Python 环境缺少app包路径导致from app.scheduler import ...导入失败。解决方法是把项目根目录加到PYTHONPATH在脚本顶部加一行set PYTHONPATH%BASE_DIR%;%PYTHONPATH%这一招在 Windows 服务版和 systemd 部署时同样适用。如果你把路径写死成C:\project\换一台机器就会废掉用BASE_DIR拼接可以保证相对路径始终有效。验证整套平台是否正常可以在命令行执行python -m app.backtest --config config/strategies/ma_cross.yaml --fast-verify快速跑一个 3 日的小样本观察是否生成output/equity_curve.csv。文件内容第一行是datetime,equity第二行日期就是策略的第一个 bar 日期。看到这个文件说明从配置读取、数据加载、Rust 计算到结果落盘这一整条链路是通的。本文还有配套的精品资源点击获取 量化PaaS架构解析：Python编排+Rust加速的多策略回测框架
简介这是一份以Python为核心的量化交易PAAS平台源码面向量化开发者与金融IT人员解决策略研究、回测、模拟交易到实盘执行的工程化落地问题。代码库由590个文件构成包括170个Python模块、134个Rust组件、40项YAML参数配置、30个Shell自动化脚本及dockerfile、Markdown文档等压缩包约4.19MB目录按模块化架构组织便于二次开发。平台整合了分布式任务调度、金融数据管理、多策略历史回测、交易模拟测试及可视化分析等完整工作流支持本地私有化部署可适配证券市场、期货市场及自定义金融产品。目前已有67人学习下载适合需要搭建量化投研平台的团队或个人参考尤其对Rust与Python混编、任务编排等实现具有直接借鉴价值。1. 这不是一个回测脚本而是一套量化PaaS的骨架做了几年量化交易你一定经历过这种痛策略代码在 Jupyter 里跑得有模有样换到定时任务就各种崩回测用的行情接口和实盘接口对不上多策略想并行评估得自己折腾进程池和锁。这套源码的核心价值是把这些散落在各处的工程问题做了一层收敛——它用 Python 组织任务流用 Rust 承担计算热点用 YAML 管理策略参数再加上分布式调度和本地化部署形成了一套完整的多策略回测与交易执行框架。项目由 480 份文件组成其中 170 个 Python 模块、134 段 Rust 组件、40 份 YAML 配置包含从数据管理、历史回测、模拟交易到实盘执行的完整链路。适合两类人一是想快速搭建自有量化平台、不愿从零写撮合和风控的团队二是正在研究 Python 与高性能语言混合编程的开发者。2. 任务编排与分布式调度从启动脚本到任务分发的落地路径量化平台里耗时最长的不是策略本身而是数据检查和任务编排。你会看到项目根目录下放着start.bat、glances.conf、pip.conf这些容易被忽略的文件它们分别解决启动引导、资源监控和依赖安装这三个基础问题。下面按实际使用顺序拆开讲。2.1 start.bat 启动流程与依赖环境准备Windows 环境下的启动脚本通常承担两层责任检查 Python 环境、按顺序拉起各个服务。典型的start.bat长这样echo off setlocal enableextensions set PYTHON_CMDpython set BASE_DIR%~dp0 set LOG_DIR%BASE_DIR%logs if not exist %LOG_DIR% mkdir %LOG_DIR% %PYTHON_CMD% -c import numpy, pandas, yaml 2nul if errorlevel 1 ( echo [ERROR] Missing dependencies, running pip install... pip install -r requirements.txt ) %PYTHON_CMD% -m app.scheduler --config config/scheduler.yaml %LOG_DIR%\scheduler.log 21 %PYTHON_CMD% -m app.backtest --config config/backtest.yaml %LOG_DIR%\backtest.log 21这里先用python -c import ...做依赖探测缺包时自动走pip install避免每次启动都重新解析全部依赖。后台任务用 log 21把日志重定向到独立文件防止一个服务崩溃把整个控制台输出冲掉。%BASE_DIR%确保了脚本在任意目录下双击都能定位到项目根。关键区别在于不要把start.bat当成一次性启动工具它本质上是任务编排的入口。调度服务、回测服务、API 服务可以分开启动也可以按依赖顺序合并启动。下面这张表是启动脚本里最常出现的配置项配置项作用常见值PYTHON_CMD指定解释器路径python或/opt/venv/bin/pythonBASE_DIR项目根目录%~dp0Windows或$(pwd)LOG_DIR日志输出目录./logs--config指向 YAML 任务配置config/*.yaml21合并标准错误与标准输出固定写法在多机部署场景里这种批处理脚本会被 systemd 或 supervisor 替代但核心逻辑相同先探活、再启动、最后落日志。2.2 任务队列与分布式调度器的选型这套平台的任务调度层没有盲目引入 heavyweight 框架而是用 Python 写了一个基于队列的任务分发模块。常见做法是在app.scheduler里把任务拆成「定时触发」和「事件触发」两类。定时任务用APScheduler维护 Cron 表达式事件触发任务则走Redis队列。下面是一个简化版调度器代码# app/scheduler/dispatcher.py import json import redis from apscheduler.schedulers.background import BackgroundScheduler class TaskDispatcher: def __init__(self, redis_urlredis://localhost:6379/0): self.redis redis.from_url(redis_url) self.scheduler BackgroundScheduler(timezoneAsia/Shanghai) def register(self, task_name, task_func, cron_expr): 注册一个可调度的回测或数据任务 self.scheduler.add_job( funclambda: self._push(task_name, task_func()), triggercron, **self._parse_cron(cron_expr) ) def _push(self, task_name, payload): self.redis.rpush( quant:tasks, json.dumps({task: task_name, payload: payload}) ) def _parse_cron(self, expr): # 0 2 * * * - {hour: 2, minute: 0} parts expr.split() return {minute: parts[0], hour: parts[1]}register方法用 Cron 表达式描述任务触发时机_push把任务序列化后塞进 Redis 列表。分布式中的 worker 进程只需lpop这个队列就能做到多机消费。这种设计的好处是调度器和执行器完全解耦扩容时只需要加 worker不需要改调度逻辑。注意_parse_cron需要对秒级任务做额外控制默认场景下分钟级就够。相比直接上 Celery这种轻模式适合任务数少于 200 个、且不需要复杂路由的团队。项目里的 40 份 YAML 配置一部分就是在描述这些任务的 Cron 表达式和参数入口后面会详细展开。2.3 多机部署时的资源管理与监控配置分布式起来之后最先暴露的问题不是任务跑不完而是某台机器 CPU 被打满却不知道是哪个 worker 干的。仓库里的glances.conf就是用来统一监控多机性能的。Glances 本身是个 Python 写的跨平台监控工具glances.conf可以配置 Web 端口、刷新间隔和客户端模式[global] refresh2 check_updatefalse [web] bind0.0.0.0 port61209 [client] server192.168.1.10 port61209scheduler节点负责采集client节点从中央服务器拉数据。这样你在控制台上能看到每一台 worker 的 CPU、内存和进程状态。配合pip.conf配置内网 PyPI 镜像新机器入职后的初始化时间能压缩到两分钟以内[global] index-url http://mirrors.internal.team/simple/ trusted-host mirrors.internal.teamtrusted-host必须显式声明否则从 HTTP 源装包会被 pip 拒绝。团队内部部署时建议把requirements.txt里的版本全部 pin 死避免新机器装到不同版本导致调度结果不一致。3. 多策略回测与数据管理参数配置层与 Rust 模块的配合回测系统最容易踩的坑是「策略逻辑和数据接口纠缠在一起」。这套平台把回测拆成了策略定义、行情加载、收益计算三块其中收益计算层大量使用 Rust 组件后面详说。3.1 策略模块的输入输出与参数化约定每个策略在 Python 层都是一个类继承同一个BaseStrategy抽象类必须实现initialize和next两个方法。这样设计的目的很明确回测引擎只认这个接口策略内部怎么调仓是开发者的自由。# app/strategies/base.py class BaseStrategy: def __init__(self, params: dict): self.params params self.position 0 self.cash params.get(initial_cash, 1_000_000) def initialize(self, context): 初始化指标、缓存、连接等 ... def next(self, context): 每个bar触发一次 ... def on_data(self, bar): 回测引擎回调入口 signals self.next(self.context) return self._validate_signals(signals) def _validate_signals(self, signals): 只接受 buy sell hold 三个选项 allowed {buy, sell, hold} if not all(s in allowed for s in signals): raise ValueError(finvalid signal: {signals}) return signalssell信号这里不做数量控制的话实盘会出问题——引擎层会把整个仓位一次卖出而_validate_signals只做合法性检查。回测参数通过params字典传入比如移动平均线的窗口要同时写在策略初始化和 YAML 配置里两边一旦不对齐结果会非常诡异。3.2 YAML 配置层多策略参数如何组织项目里 40 份 YAML 文件接近一半是策略配置。拿双均线策略举例# config/strategies/ma_cross.yaml strategy: name: ma_cross_5_20 module: strategies.ma_cross params: fast_window: 5 slow_window: 20 initial_cash: 1000000 max_positions: 3 data: source: local_parquet symbols: - 000300.SH - rb888.SHF start_date: 2020-01-01 end_date: 2024-12-31 interval: 1d推荐在 YAML 里写max_positions而不是策略代码里写死这样同一份策略可以配置出不同版本做参数扫描时只需要遍历 YAML 文件。回测引擎读这个文件时会先把module字符串解析成类名再实例化并注入params。这里有个约定所有文件里的日期统一用字符串解析时再转datetime否则 YAML 会把2020-01-01解析成datetime.date对象JSON 序列化时容易出错。多策略回测的另一个关键是行情数据本地化。项目支持本地 Parquet 目录作为数据源目录结构一般按symbol/interval/year.parquet组织。回测时只加载配置中symbols指定的文件避免读全市场。表结构类似字段类型说明datetimedatetime64[ns]时间戳需要设置索引open/high/low/closefloat64OHLC 价格volumeint64成交量amountfloat64成交额价值型策略用到open_interestint64期货持仓量股票标的可以填 0加载这种数据时最常遇到的坑是时间戳时区。如果你下载的是带08:00的数据回测引擎会按 UTC 再转一次直接导致 K 线错位。建议在数据落地时就统一成Asia/Shanghai的 naive 时间不要带时区后缀。3.3 Rust 组件如何加速回测计算项目包含 134 段 Rust 组件这些不是摆设。回测里的收益计算、撮合撮合结果汇总Python 处理百万级 bar 会非常吃力Rust 正好承担这部分数值计算。常见做法是用 PyO3 把 Rust 代码编译成 Python 可以 import 的扩展模块示意代码// backtest_engine/src/portfolio.rs use pyo3::prelude::*; #[pyfunction] fn calculate_equity_curve(returns: Vecf64, initial_cash: f64) - Vecf64 { let mut equity Vec::with_capacity(returns.len()); let mut current initial_cash; for r in returns { current * 1.0 r; equity.push(current); } equity } #[pymodule] fn backtest_engine(m: Bound_, PyModule) - PyResult() { m.add_function(wrap_pyfunction!(calculate_equity_curve, m)?)?; Ok(()) }编译好后Python 侧是这样调用的import backtest_engine raw_returns [0.01, -0.02, 0.03] equity backtest_engine.calculate_equity_curve(raw_returns, 1_000_000) print(equity) # [1010000.0, 989800.0, 1019494.0]这里传入的raw_returns是策略next方法算出来的日收益率序列。Rust 侧用Vecf64接收然后逐项累乘。注意它的后缀是f64而 Python 的float精度更低传输大批量数据时会有类型转换开销。如果数据量超过 100 万条建议用 NumPy 数组零拷贝传给 Rust不要用 list。混合编程最容易忽视的是构建链。start.bat启动前必须保证.so或.pyd文件存在否则 import 直接失败。排查顺序先确认 Rust 版本与 Python 版本匹配再确认 PyO3 的abi3特性是否启用。abi3可以让我编译出的扩展同时兼容 Python 3.8–3.12省掉多版本编译成本。4. 实盘交易与模拟撮合从回测到执行的边界控制回测能跑通只是第一步真正决定这套平台能不能用于生产的是回测策略与实盘交易所之间的接口设计。这个项目的模拟撮合和实盘交易共用一个执行接口切换成本被压到最低。4.1 统一的订单执行接口接口层定义如下# app/brokers/base.py class BaseBroker: def connect(self, account_id: str): ... def place_order(self, symbol: str, side: str, quantity: float, order_type: str market): side 只允许 buy 或 sell ... def cancel_order(self, order_id: str): ... def get_position(self, symbol: str) - dict: 返回 {symbol: str, qty: float, avg_price: float} ...回测时用的SimulationBroker会先走一遍撮合逻辑再返回成交回报实盘时LiveBroker内部把同样的订单结构转换成券商或期货公司的 API 请求。这样策略层不需要关心资金账户细节只管发单和监听回报。这里需要你注意一个边界回测环境里订单是即时成交的实盘里可能挂单半天不动。所以策略发出sell信号后平台会先查get_position()如果返回None就丢弃这次信号并记录日志。这个保护逻辑写在执行器里不写在策略里保证上实盘时不会因为异步延迟产生「裸卖空」。4.2 模拟撮合与滑点模型模拟撮合最有价值的点是滑点模型。许多回测平台把滑点设为一个固定百分比例如0.1%这在波动率大的标的上误差非常大。这个项目支持两种滑点按固定价位、按盘口深度估算。下面是一个撮合器核心逻辑# app/execution/matching.py def execute(bar, order, slippage_modefixed, slippage_value0.02): bar 是一个字典包含 open/high/low/close/volume 返回成交价和成交量 if order[side] buy: fill_price bar[open] * (1 slippage_value) if slippage_mode fixed else min(bar[high], bar[open] slippage_value) fill_qty order[quantity] else: fill_price bar[open] * (1 - slippage_value) if slippage_mode fixed else max(bar[low], bar[open] - slippage_value) fill_qty order[quantity] return {price: round(fill_price, 6), quantity: fill_qty}slippage_modefixed适合股票slippage_value0.02表示下单价格上浮 2 个基点。注意这里用的是bar[open]因为分钟级别的回测中bar 收盘后你才知道信号下单时最合理的参考价是下一根 K 线的 open。很多刚上手的人在这点犯错误用当前 bar 的 close 成交然后发现回测收益高得离谱——那是未来函数。如果你使用盘口模式需要传入一个订单簿深度数据源而且slippage_value的含义会变成「最多容忍滑 2 个 tick」代码逻辑要按bar[high]和bar[low]做边界限制。两种模型在合成数据上差异不大但在真实盘中盘口模式的成交回报会分散到每笔价格区间导致持仓成本分配更复杂。4.3 持仓、风控与撤单重启执行层还有一个容易被忽视的问题进程重启后本地记录的手数还准不准。平台的持仓管理模块支持从 broker 拉取真实仓位做本地重建而不是单纯依赖内存字典。风控规则表也放在配置里# config/risk/limits.yaml risk: max_position_ratio: 0.6 max_single_order_value: 200000 max_daily_loss: 50000 allow_short: false close_on_signal_end: truemax_daily_loss是每日最大回撤限额达到后执行器所有新订单都会被拒掉。allow_short默认关闭防止股票策略误开空头。这些规则是在BaseBroker.place_order之前拦截的属于前置风控此外平台还支持撤单重启恢复启动时读取本地order_history.json把未完成订单标记为canceled避免重复挂单。5. 私有化部署的最终检查监控、依赖与启动排错这里不谈概念只讲把平台真正跑起来时最容易卡住的三件事。第一是glances.conf的 Web 端口在云主机上用不了——因为默认绑定了0.0.0.0但安全组规则没放行 61209 端口你会一直在容错期间绕墙。确认监听用ss -lntp | grep 61209如果你是在本机调试把bind改成127.0.0.1是更稳的选项。第二是pip.conf与requirements.txt的配合。仓库里放了一个pip.conf模板但在有内外网隔离的机构里它必须放在%APPDATA%\pip\pip.iniWindows或~/.pip/pip.confLinux才会生效。启动报ModuleNotFoundError: No module named numpy时先看是不是pip.conf指向的镜像源缺包再考虑是不是 Python 版本不兼容。项目大量使用 Rust 组件旧版本 Python 3.7 会被 PyO3 的编译产物拒之门外推荐直接用 Python 3.10 或 3.11。第三是start.bat启动后进程秒退。常见原因不是脚本里有语法错误而是%PYTHON_CMD%指向的 Python 环境缺少app包路径导致from app.scheduler import ...导入失败。解决方法是把项目根目录加到PYTHONPATH在脚本顶部加一行set PYTHONPATH%BASE_DIR%;%PYTHONPATH%这一招在 Windows 服务版和 systemd 部署时同样适用。如果你把路径写死成C:\project\换一台机器就会废掉用BASE_DIR拼接可以保证相对路径始终有效。验证整套平台是否正常可以在命令行执行python -m app.backtest --config config/strategies/ma_cross.yaml --fast-verify快速跑一个 3 日的小样本观察是否生成output/equity_curve.csv。文件内容第一行是datetime,equity第二行日期就是策略的第一个 bar 日期。看到这个文件说明从配置读取、数据加载、Rust 计算到结果落盘这一整条链路是通的。本文还有配套的精品资源点击获取