简介这是一份基于Python与Tushare接口的个人股票伺服系统完整源码包面向量化投资爱好者和个人投资者用于实现策略自动化选股、交易模拟、模型验证与数据分析。压缩包共20个文件大小仅455KB以10个Python源码文件为主另含4个txt文档记录依赖、版本与标签信息同时提供SQL数据库脚本、Excel说明文档和Markdown指南结构清晰。目前已有92人学习使用。项目代码按数据访问、数据库操作、回测、工具、测试等模块划分btstock目录存放回测相关源码test目录包含功能测试用例util与db模块分别负责工具函数与MySQL数据库操作同时附有依赖清单和数据库初始化脚本读者可快速搭建环境复现从tushare获取行情数据到策略回测、结果分析的全流程。这套源码不仅能为个人量化交易系统提供清晰的学习骨架也可作为二次开发的基础工程。1. 项目整体设计与思路拆解1.1 项目背景个人量化系统的三个核心诉求先说说我为什么做这个项目。做股票交易的人都会遇到一个很现实的问题盯盘太耗精力手动操作容易受情绪干扰而且历史数据一多想验证某个策略到底靠不靠谱手动翻K线根本没法统计。于是很自然就想到能不能用Python把这套流程串起来做成一个自用的伺服系统——这个词借用了工业控制里的概念意思就是让系统自己去跟踪目标、执行任务人只负责定义规则和审核结果。这套系统要解决的三个核心问题和绝大多数个人量化需求的排序是一致的。第一是策略自动化选股每天收盘后自动跑一遍选股逻辑把符合条件的标的筛出来不用手动翻几百只股票。第二是交易执行策略产生信号后系统能按设定的规则下单在很多场景里也叫半自动交易人做最终确认机器负责速度与纪律。第三是模型验证与数据分析任何策略在实盘之前都必须先经过历史数据回测并且要用一套科学的指标来评估策略好坏不能凭感觉说看起来赚了。适合参考这个项目的人有两类一类是有Python基础、想踏入量化投资门槛的开发者另一类是已经有投资经验、但苦于复盘和统计效率太低的人。前者能在这里看到完整的系统骨架后者能借鉴一套数据驱动决策的方法论。1.2 为什么选Python tushare这套技术组合选型这件事我在项目里反复权衡过。Python在量化领域几乎是事实标准原因有三语法简单、生态丰富pandas、numpy、matplotlib一套组合拳打天下、社区资料多。你遇到任何一个问题几乎都能搜到现成的解决思路。更重要的是Python的灵活性能让策略研发和系统开发用同一种语言完成不用在脑子里切换上下文。tushare作为数据源解决了个人开发者最头疼的数据获取问题。它提供股票日线、分钟线、财务指标、资金流向、指数成分、复权因子等几十类结构化数据通过简单的HTTP接口就能批量拉取。相比自己写爬虫去抓行情tushare的数据有统一字段格式还有数据清洗和复权处理节省了大量重复劳动。尤其对于个人开发者用tushare搭数据层能快速聚焦到策略本身而不是把时间耗在维护数据采集上。1.3 系统模块拆解数据层、策略层、执行层整个系统的架构我没有做得很复杂核心是三个层次加上一个贯穿全局的调度数据层负责从tushare拉取行情、财务等数据做清洗、对齐、落库。本地用SQLite或CSV文件存储后面做回测时反复读取也不怕接口限流。策略层接收数据层的输出执行选股策略比如多因子打分、趋势突破、均值回归输出带信号标注的结果表。执行层根据策略信号生成交易指令结合账户持仓和资金情况做仓位计算。实盘部分预留了与券商接口对接的适配位回测部分则直接走历史行情。调度模块用APScheduler或系统定时任务把每日收盘后更新数据→跑策略→生成次日候选清单这条链路自动化。这个分层设计的好处是每一层都可以独立替换。今天用tushare明天换其他数据源只动数据层的适配代码今天用均线策略明天换机器学习模型策略层单独改。系统不会因为局部调整而全线崩盘这对长期维护自己项目的人来说特别重要。2. 数据层实现tushare使用要点与数据仓库搭建2.1 tushare数据接入注册、Token与权限开通tushare的使用有门槛但门槛主要在积分体系而不是技术难度。官方网站注册后你会拿到一个专属的token字符串这是所有API调用的身份凭证。项目里我用一个配置文件存放token所有数据模块从配置读取避免把token硬编码在代码里、提交到Git仓库后泄露。积分决定了你能调用哪些接口以及每分钟的调用频率。比如基础积分能调用日线行情但分钟线、财务深度数据、龙虎榜这类高端接口就需要更高积分。积分的获取方式对个人开发者很友好注册、完善资料、每日签到、社区贡献都会给积分。我的建议是先从日线数据和基础财务数据开始这些足够支撑绝大多数中低频选股策略先把链路跑通再逐步扩展。注意tushare的接口有频率限制比如每分钟最多调几百次。批量拉取全市场几千只股票的数据时一定要在代码里加sleep控制节奏或者做增量更新——只拉最近几个交易日的增量数据而不是每次都全量刷新。2.2 数据拉取与本地落库的关键代码来看项目里最核心的一段数据拉取代码。这个函数的目标是把指定股票池的日线数据拉取下来清洗后存入本地import tushare as ts import pandas as pd import time from datetime import datetime, timedelta # 初始化接口 ts.set_token(your_tushare_token) pro ts.pro_api() def fetch_daily_batch(ts_code_list, start_date, end_date): 批量拉取日线行情带异常重试与频率控制 all_data [] for ts_code in ts_code_list: for retry in range(3): try: df pro.daily( ts_codets_code, start_datestart_date, end_dateend_date ) if not df.empty: all_data.append(df) time.sleep(0.3) # 控制频率避免触发限流 break except Exception as e: print(f拉取 {ts_code} 失败(第{retry1}次): {e}) time.sleep(1) if all_data: return pd.concat(all_data, ignore_indexTrue) return pd.DataFrame()这段代码里有几个容易踩坑的地方。第一是复权处理pro.daily()是未复权数据但选股和回测时最好用前复权数据否则分红送股会造成价格跳空策略信号会失真。tushare提供了pro.adj_factor()复权因子接口需要把日线价格乘以复权因子得到复权价。第二是股票代码格式tushare的代码统一是000001.SZ600000.SH这种带交易所后缀的格式和平时看到的纯数字代码不一样写选股逻辑时要注意转换。数据落库我用的是SQLite原因很简单它是单文件数据库免安装、免运维、备份就是拷贝一个文件特别适合个人项目。建表时给股票代码和日期加上联合主键避免重复数据后续查询还快。2.3 增量更新策略让数据层永远不缺数据数据更新不能每次全量拉。A股5000多只股票全量拉一次日线要十几分钟效率低且容易触发限流。我在项目里维护了一张记录表存储每只股票最新拉取到的交易日下次运行时只拉最新交易日之后的增量数据def incremental_update(ts_code_list): today datetime.now().strftime(%Y%m%d) for ts_code in ts_code_list: last_date get_last_stored_date(ts_code) # 从库中查该股票最后一条记录的日期 if last_date and last_date today: continue start last_date if last_date else 20200101 df fetch_daily_batch([ts_code], start, today) save_to_db(df)这个思路和大厂数据仓库的增量抽取本质一样只是个人项目不用搞那么重的框架。实测下来维护几百只股票的自选池每天增量更新不到30秒收盘后跑一次第二天开盘前数据就是齐的。3. 策略自动化选股从因子构建到信号生成3.1 策略怎么定先有逻辑再写代码很多新手做量化容易犯一个错误先找数据再想策略最后代码写出来自己都说不清买卖依据是什么。我在这个项目里的习惯是先定义清晰的投资逻辑再翻译成可计算的因子。以我项目里跑通的其中一个策略为例——低估值动量双因子策略逻辑特别朴素买便宜的好公司低估值同时股价趋势向上动量。估值用市盈率PE分位数衡量动量用过去60个交易日涨跌幅衡量。两个因子各自打分后加权汇总取总分前20名的股票作为候选池。为什么选这个组合因为单因子很容易失效低估值的票可能是价值陷阱高动量的票可能追高被套。两个维度互相补充至少能在逻辑上形成又好又便宜还有趋势的组合回测起来心里也踏实。3.2 因子计算的代码实现与数据对齐计算因子的第一步是把所需数据对齐。tushare的日线数据是每只股票单独一张表但做横截面选股时需要的是每个交易日、所有股票的数据排在一起也就是宽表结构。用pandas的pivot_table和merge就能完成对齐def calculate_factors(price_df, pe_df): price_df: 包含股票代码、日期、收盘价的日线数据 pe_df: 从tushare财务接口获取的市盈率数据 # 1. 把收盘价转成宽表行是日期列是股票代码 close_wide price_df.pivot_table( indextrade_date, columnsts_code, valuesclose ) # 2. 计算动量因子过去60日的累计涨幅 momentum close_wide.pct_change(60) # 3. 处理PE因子按每日全市场股票做分位数排名 pe_rank pe_df.groupby(trade_date)[pe].rank(pctTrue) # 4. 因子合成动量排名的50% 反向PE排名的50%PE低则排名高 score 0.5 * momentum.rank(axis1, pctTrue) \ 0.5 * (1 - pe_rank) return score这里有个极其重要的细节因子计算时绝对不能使用未来数据。比如动量因子算的是截止到今天收盘的过去60日涨幅那么因子值只能用于今天的收盘决策或明天的开盘交易不能用来买今天的股票。项目里我对交易信号做了严格滞后处理所有信号在产生后的下一个交易日开盘才生效。另一个常见坑是财务数据的时点对齐。PE里的净利润是季报披露的但季报有披露延迟——一季报可能4月底才出但你在4月1号就用了这份数据就属于用了未来数据。tushare有f_ann_date公告日期字段正确做法是按公告日期对齐而不是按报告期对齐。这个坑不注意到回测结果会虚高得离谱。3.3 选股信号自动化定时任务让系统自己跑起来代码写好了还得让它每天自动运行。项目里我用APScheduler做任务调度核心任务有两个每天下午17点收盘后更新数据17:30跑选股策略并生成报告。用APScheduler而不是Windows计划任务是因为调度逻辑写在项目里换电脑、换服务器都能直接跑起来不依赖系统环境。from apscheduler.schedulers.blocking import BlockingScheduler from datetime import datetime def job_update_data(): update_all_stocks_daily() def job_run_strategy(): signals generate_signals() save_signals_to_cache(signals) send_report(signals) # 推送候选清单到微信或邮件 scheduler BlockingScheduler() scheduler.add_job(job_update_data, cron, hour17, minute0) scheduler.add_job(job_run_strategy, cron, hour17, minute30) scheduler.start()这套调度跑起来之后系统的自动化目标就完成了第一环每天收盘后选股清单自动出现在你面前打开手机就能看不用打开电脑手动跑脚本。4. 回测、交易执行与模型验证的落地实践4.1 回测框架的选择先用轻量级再谈精细化回测是量化系统里最烧脑的部分但我的原则是别一上来就搞复杂的回测引擎。许多人一出手就想着用backtrader、zipline这些专业框架结果光学框架就要两周回测结果还不一定信得过。项目初期我先写了一个简单的向量化回测几百行代码就能完成def backtest(signals, price_df, initial_capital1000000): signals: 每日每只股票的目标仓位0或1 price_df: 每日收盘价宽表 # 收益对齐信号产生于T日实际交易于T1日开盘 exec_signals signals.shift(1) # 计算每日组合收益 daily_ret price_df.pct_change().fillna(0) portfolio_ret (daily_ret * exec_signals).sum(axis1) / exec_signals.sum(axis1) # 计算净值曲线 nav (1 portfolio_ret).cumprod() * initial_capital return nav nav backtest(signal_score, close_price)向量化回测的局限是它假设交易按收盘价/开盘价全部成交不计冲击成本和手续费同时不考虑涨跌停买不进的情况。但作为策略初筛它已经足够回答这个策略方向对不对的问题。等策略做大了再迁移到事件驱动的回测框架不迟。4.2 交易执行合规对接是唯一正确的路线说到交易环节我必须强调一个原则任何自动化交易都必须通过合法合规的渠道实现。券商官方开放的交易接口是唯一可选的对接方式所有自建通道、绕过监管的做法都是绝对禁区风险巨大。项目里我在执行层做了两层设计手动确认模式半自动策略产生买卖信号后系统生成指令列表推送到微信或邮件。人收到消息后在券商手机软件里手动执行。这种模式虽然还要人点按钮但已经把选什么什么时候买变成机器决策大幅减少了情绪干扰。程序化执行模式预留通过券商官方API实现自动化下单。需要说明的是这类接口有严格的开通门槛资产规模、交易经验、考试评测而且各省监管口径有差异。个人开发者要真想走这条路务必先去自己所在券商咨询开通条件千万不可听信网上所谓的曲线做法。实盘下单必须做一个风控模块核心是仓位控制。单只股票仓位上限不超过总资金的20%行业分散度有约束单日最大回撤达到5%就暂停交易。这些规则看起来简单但真到回撤时能救命。4.3 模型验证回测指标全解析与过拟合防守策略好不好不能只看赚没赚钱要看多个维度。我在项目里定义了一套验证指标覆盖收益、风险、稳定性三个层面指标名称计算公式判读标准年化收益率净值年化后的增长率至少要跑赢银行理财否则没有实盘意义最大回撤净值从峰顶到谷底的最大跌幅心理承受底线比如超过20%就要反思夏普比率(年化收益 - 无风险利率) / 年化波动率大于1算合格大于2算优秀胜率盈利交易次数 / 总交易次数但胜率低不代表策略差配合盈亏比看盈亏比平均盈利 / 平均亏损大于2说明赚大亏小逻辑健康除了指标过拟合是个人量化最大的敌人。最常见的过拟合表现是回测曲线漂亮到不像话实盘一跑就翻车。我做了三重防守第一参数要设置成钝感的稍微改几个值策略表现不应剧烈变化否则就是过度拟合了历史噪声第二做样本外测试用前70%的数据调参后30%的数据验证验证段表现不行就枪毙策略第三做多市场环境测试分别看牛、熊、震荡市里的表现只适合单一环境的策略不值得实盘。未来函数是另一个高频错误前面提到的财务公告时点对齐就是典型。项目里我在数据层就统一处理了所有可能泄露未来信息的地方确保任何策略拿到的数据都是在那个时间点真实可获得的。5. 数据分析与可视化的工程实践数据驱动决策有数据还得看得懂。项目里我把分析结果沉淀成一份每日更新的HTML报告内容包括候选股票的因子值明细、近30日净值曲线、当前持仓盈亏分布。这里我用到的是matplotlibpandas的组合中文字体配置是个坑Windows上和Linux上字体路径不一样我在项目里统一指定了字体文件import matplotlib.pyplot as plt import matplotlib.font_manager as fm # 解决matplotlib中文乱码 font_path C:/Windows/Fonts/msyh.ttc # 微软雅黑Linux下换成思源黑体路径 font_prop fm.FontProperties(fnamefont_path) plt.rcParams[font.family] font_prop.get_name()每日报告里最有价值的是因子暴露分析。简单说就是回答一个问题我这个组合到底是靠什么赚钱的比如组合在估值因子上暴露度高说明策略赚的是估值修复的钱如果一段时间估值因子失效组合却还在赚钱说明可能是运气或市场风格切换。这个维度的分析能用起来才算是真正把数据变成了决策依据。6. 常见问题与排查技巧实录6.1 高频问题速查表问题现象可能原因解决方案tushare调用报抱歉您没有访问该接口的权限积分不足接口未开通去官网查看接口的积分要求先完成新手任务积累积分拉到的价格和行情软件对不上未做前复权处理用adj_factor因子对原始价格做复权计算策略选股结果里出现ST股票未过滤退市风险股在选股前统一过滤ST、上市不满60天的次新股回测收益率高得离谱可能用了未来财务数据检查财务对齐逻辑确认按公告日期而非报告期对齐定时任务在电脑睡眠后不执行系统休眠中断了任务服务器上部署或设置电脑不休眠模式程序跑一段时间后内存暴涨数据全部放在内存里没释放及时用del删除大DataFrame或改用增量处理方式6.2 我在这个项目里踩过的三个大坑第一个坑是token泄露。有一版代码我把token直接写死在配置里结果上传到公共代码仓库第二天就收到提示说token被滥用了。现在的做法是把token写在本地环境变量里代码通过os.getenv()读取任何配置都不进版本库。这一点对个人项目尤其重要——看起来是小问题处理不好前面所有工作都得白费。第二个坑是股票代码格式混乱。数据源、回测框架、交易接口三套体系的代码格式完全不统一有的是000001纯数字有的是000001.SZ有的是sz000001。我专门写了一个统一的代码转换模块所有接口进出的代码都经过这一层做标准化不然在对接时迟早会在这个地方栽跟头。第三个坑是高估了定时任务的可靠性。最开始我把系统部署在个人电脑上Windows更新重启一次任务就不跑了第二天选股清单空白的。现在我的建议是第一把数据更新和策略运行设计成可重入的漏跑一次后补跑不会出问题第二有条件的还是放到云服务器上跑个人电脑用来做开发调试就好。6.3 后续扩展方向这个系统跑顺之后可以往三个方向扩展加入多策略组合管理不同策略分配不同资金权重、引入机器学习模型做收益预测辅助因子选股、结合盘口与资金流数据做日内策略。每一个方向都足够深但核心骨架和数据层已经打好底子扩展时不需要推倒重来。最后说点实在话。个人做量化系统最容易死掉的环节不是技术实现而是持续迭代的耐心。策略会失效数据接口会变更系统要跟着调整。我在实际使用中最深的体会是把系统当成一个长期维护的产品去对待而不是一次性写完的脚本。少追求华丽的功能多关注链路是不是每天都稳定跑通——数据更新了没有、策略信号正不正常、回测结果有没有异常偏离。先把这些基础问题管好再谈策略迭代这个系统的价值才能慢慢显现出来。本文还有配套的精品资源点击获取