1. 项目概述OpenStock 解决了什么问题做投资或者对量化交易感兴趣的朋友多半都经历过这样一个尴尬阶段市面上的行情软件、选股工具很多但数据封闭在别人的生态里策略逻辑写死在界面上想加点自己的筛选条件、想跑个回测、想把自己看好的逻辑落地成代码发现寸步难行。免费的工具功能受限付费的工具价格不菲而且数据接口、策略框架这些东西用起来总觉得隔了一层。OpenStock 这个开源项目核心就干一件事帮你从零搭起一套属于自己的股票数据分析和策略回测平台。它不是一个“看盘软件”而是一套能跑在你本地机器上的完整系统——从行情数据采集到数据入库存储再到技术指标计算、策略回测、可视化展示整条链路都是你的数据是你自己的代码是开源的逻辑完全透明可控。换句话说你得到的不是一个“功能更多的炒股软件”而是一个“可以随意改造的股票数据工作台”。想要自定义选股因子自己写。想要接入不同的数据源自己改。想要把回测结果输出成报表自己加。项目本身的定位就是一块地基你想盖什么样的房子取决于你的需求。这套项目最适合三类人第一类是刚开始接触量化交易、想搞明白行情数据是怎么流转的程序员第二类是手里有投资想法、想把“我觉得这个策略能赚钱”变成“回测数据显示这个策略年化收益率是多少”的投资者第三类是跟我一样单纯不满足于现成工具、什么都想自己掌控的技术爱好者。2. 整体架构与技术选型为什么这么设计2.1 模块拆分从数据到决策的完整链路一个股票分析系统再怎么花哨底层的逻辑都不复杂。拆开来看就四步拿数据、存数据、算指标、看结果。OpenStock 的整个架构也是按照这个链路来的。数据采集层负责从公开渠道获取股票行情数据包括日K线、分钟K线、实时报价、基本面数据等。这一层在设计时最容易被低估但恰恰是最关键的一层——数据源挂了后面所有模块都是空转。所以实际部署时我建议给数据采集模块单独设置定时任务而且要支持多源切换留好容错机制。数据存储层用的是关系型数据库我部署时用的 PostgreSQL你也可以用 MySQL。为什么不用 MongoDB 这类非关系型数据库因为行情数据本质上是时间序列数据查询模式非常固定——按股票代码查某段时间的K线、按日期查全市场行情这些场景用关系模型表达最自然而且后续做数据回补、做条件筛选时 SQL 写起来也顺手得多。另外事务支持对数据一致性也很重要采集任务中断时能回滚不至于留下半拉子数据。策略计算层是系统的核心逻辑所在。这里实现了常见的移动均线、MACD、RSI、布林带等指标计算以及简单回测引擎。这一层设计最关键的地方在于把“指标计算”和“策略逻辑”解耦——指标计算是纯函数输入K线数据输出指标序列策略逻辑则是基于指标信号产生买卖指令。这样分开以后新增一个策略只需要写策略部分不用动指标库。可视化展示层负责把计算结果变成人看得懂的图表。K线图、净值曲线、回撤面积图、信号标记这些是判断策略好坏最直观的途径。2.2 技术栈选型为什么选这些组件这套项目后端用的是 Python这个没什么悬念。金融数据分析领域 Python 的生态优势太明显了——pandas、numpy 处理时间序列数据比 Node.js、Go 舒服太多了回测、指标计算、统计分析这些场景直接站在巨人的肩膀上。前端则是典型的 Web 方案数据可视化层用的是 EChartsK线图和指标叠加图做得很成熟交互效果也顺滑。数据库层刚才说了推荐 PostgreSQL。一个很现实的原因是你后续如果要跑稍微复杂一点的策略回测SQL 里写窗口函数、做时间范围聚合PostgreSQL 比 MySQL 强得多。数据采集这块用的是 HTTP 请求加解析的方式从公开数据源拉取再通过 ORM 落库。整个架构跑下来如果你的数据量在几千只股票、几年日K线的规模单机部署完全扛得住。我自己的部署环境是一台四核八G的云主机运行起来很轻松。2.3 架构设计的核心取舍这套方案在设计上有一个很明确的取舍——单机优先、简单优先。它没有一上来就上消息队列没有把采集、计算、展示拆成多个微服务也没有引入大数据组件。为什么因为绝大多数个人使用场景下单机方案在性能上完全够用而引入分布式架构带来的复杂度——部署难度、运维成本、故障排查难度——会直接劝退90%想自己搭建的人。但架构虽然简单代码层面还是做了不少低耦合的设计。比如数据采集接口和数据源解析就是分开的默认支持一种数据源你想接入其他数据源时只需要新写一个解析器不用动采集框架本身。策略引擎也做了接口化处理内置的示例策略只是参考留了足够的扩展点。这就像搭积木核心模块之间接口稳定但每个模块内部你可以随便折腾。3. 从零搭建 OpenStock完整部署实录说干就干。下面这套步骤是我自己从裸环境一步步踩出来的每一步都是实际验证过的照着走基本不会卡壳。3.1 环境准备先把炕烧热OpenStock 对硬件的要求不高最低配个双核CPU、4G内存的机器就能跑基础功能。我建议最好有一台能7×24小时开机的机器——不管是你手头的旧笔记本、一台小型云主机还是家里的NAS都行。因为数据采集任务往往在收盘后或者固定时间点跑人不能总守在旁边。操作系统上Ubuntu 22.04 LTS 是我用的环境CentOS、Debian 也都能跑。Python 版本建议 3.10 以上这次我装的是 3.11兼容性不错pandas、numpy 这些核心库都有预编译包不用自己编译源码。代码获取直接用 Git 从仓库拉取这个没什么好说的。拉下来以后我习惯先建一个虚拟环境再装依赖避免把系统全局环境搞乱python3 -m venv venv source venv/bin/activate pip install -r requirements.txt依赖装完后先执行启动脚本把服务拉起来。这时候不要着急配数据源先确认系统本身能正常运行。运行起来后访问本地的 HTTP 端口能看到系统界面就说明基础环境没问题。这里有个容易忽略的点.env环境变量文件里面数据库连接、服务端口、数据源地址都是从这里读取的。部署之前要仔细检查里面每一项配置尤其是数据库连接串有没有写对。我第一次装的时候就是漏改了默认用户名导致后面所有任务都报数据库连接错误排查了大半天。3.2 数据库初始化搭好数据仓库数据库是整套系统的地基这一步我建议不要跳过哪怕你完全没接触过 PostgreSQL也花点时间把基础概念过一遍。安装好 PostgreSQL 之后需要创建一个独立的数据库用户和数据库实例。生产环境一定要设置强密码不要用默认密码这算是我吃过亏之后长记性的地方——曾有一台测试机器用的弱密码日志里能看到一堆恶意的连接尝试。初始化命令很简单项目里一般会内置一个 schema 初始化脚本直接执行就能把数据表结构建好。核心表包括股票基本信息表、日K线表、分钟K线表、策略配置表、回测结果表。这些表会从零开始把你的本地数据库变成一套完整的行情数据中心。初始化完成后可以用 SQL 查一下表结构是否正常比如看看股票表里有没有数据此时应该是空的确认表都建好了再继续下一步。3.3 采集第一批数据整个流程跑通初始化完成后就要开始采集数据了。这一步是整个系统“活”起来的开端——只有数据进到了数据库里后面的所有操作才有意义。采集工具有两种用法。一种是手动触发适合你刚部署完想立刻看到效果的时候另一种是配置定时任务适合长期运行、每天自动增量更新数据。我两张方式都在用手动触发用于验证数据源是否正常定时任务用于日常维护。第一次采集建议只选择少量股票比如五六只蓝筹股然后设定一个较短的时间范围比如最近一年。这样做的目的是快速验证整条链路是否打通数据源能不能连上、解析逻辑有没有写错、数据能不能正确落库。如果一上来就全量拉取几千只股票、十几年历史数据哪怕中途某个环节出错排查问题的范围也会大得多。采集完成后用 SQL 查一下K线表的行数确认确实有数据进来了再顺手查一下最早和最晚的交易日期检查数据范围是否正确SELECT COUNT(*) FROM daily_bars; SELECT MIN(trade_date), MAX(trade_date) FROM daily_bars WHERE symbol 600519;看到数据落库的那一刻整套系统就算正式跑起来了。这时候你就可以用系统自带的查询接口拉取任意一只股票的历史K线验证前端展示是否正常。3.4 首次运行与配置验证别急着上策略系统跑通之后我强烈建议先花几天时间观察一下运行状态。很多人一上来就急着往系统里堆策略、写指标结果基础数据质量都没验证过后续所有回测结果都是不可信的。验证数据质量有一个很朴素但很管用的办法挑一只你熟悉的股票把系统里的K线数据和公开行情对比一下。看几个关键点——某个时间段的收盘价是否一致、历史高低点是否对得上、停牌日是否被正确处理。如果这些都和公开行情一致说明数据链路是可信的可以开始下一步了。我自己在实际使用中发现不同数据源的历史数据在某些股票上会存在细微差异一般是复权因子处理方式不同导致的。前复权、后复权、不复权这三种数据对技术指标计算和回测结果的影响是本质性的——尤其做策略回测时你不可能用不复权的价格来计算收益率因为分红送转会造成价格跳空导致虚假的涨跌信号。4. 核心功能实操让数据产生价值系统搭起来了数据也入库了接下来才是重头戏——怎么利用这套系统真正做一些有价值的事情。4.1 技术指标计算从裸K线到量化信号技术分析听起来玄乎本质上其实就是用数学公式对历史价格做变换试图发现价格运动的规律。OpenStock 内置了一套常用的技术指标计算模块但我更建议你理解这些指标的原理之后再使用它们——不然你根本不知道什么时候该信任指标信号什么时候该无视它。拿最基础的移动平均线举例。5日均线就是最近5个交易日收盘价的算术平均值20日均线是最近20个交易日的平均值。均线的本质是平滑数据、过滤噪声让你透过短期波动看到一段时间的价格重心在哪里。当短期均线上穿长期均线时代表最近的价格重心在抬升这就是所谓的“金叉”。但如果你不理解这个原理仅仅机械地执行“金叉买入、死叉卖出”大概率会亏钱——因为震荡行情里均线会反复交叉给你一堆虚假信号。MACD 指标稍微复杂一点它本质上是对均线系统的再度平滑和放大。OpenStock 的策略模块里内置了 MACD 示例策略你可以直接查看它的实现代码理解指标的计算过程。我在部署后做的一件很有意义的事情就是把几个核心指标的 Python 代码都读了一遍然后自己重新实现了一遍再和内置实现的结果对比确保完全一致。这个过程不必多说代码量其实不大但收益非常大——不在于你多写了多少代码而在于你真正建立起了“我用的指标到底是什么”的确定感。4.2 策略回测把你的想法变成数字回测是量化交易最核心的环节之一。所谓回测就是把一条策略放在历史数据上“模拟运行”看按照这个策略买卖在过去几年里能赚多少、亏多少、最大回撤是多少。OpenStock 的回测引擎支持两种策略定义方式。一种是直接在回测页面配置参数——选择技术指标、设定买入卖出阈值、指定持仓周期系统自动完成回测。另一种是写 Python 策略类重写买入信号和卖出信号两个方法实现完全自定义逻辑。我建议你先用第一种方式跑通流程理解回测报告里的各项指标含义再进阶到第二种方式去写自己的策略。第一次跑回测我建议用最简单的策略——比如“20日均线之上持有20日均线之下空仓”。这个策略足够简单回测速度快而且逻辑容易理解。跑完之后重点看几个指标总收益率、年化收益率、最大回撤、夏普比率、胜率这些。最大回撤尤其重要——它告诉你这套策略在历史最差情况下会亏多少是衡量策略风险最直观的指标。这里需要注意一个核心陷阱过拟合。很多人跑回测发现结果很棒收益率翻倍、回撤很小但实盘一做就亏。很可能就是策略在历史数据上被拟合过度了——你不断调整参数让策略在已知的历史数据上表现完美但这个完美是“事后诸葛亮”对未来的预测能力极差。怎么避免交叉验证。把数据按时间切分成训练段和验证段在训练段调好参数在验证段模型没见过的数据上测试策略表现。如果验证段结果也不错才说明策略有实际意义。4.3 可视化看板用图表说话OpenStock 的可视化模块是这套系统最有“科技感”的部分也是每次给别人展示时最直观的部分。K线图是核心——每根蜡烛代表一个交易周期实体部分是开盘价到收盘价之间上下影线代表最高价和最低价范围。K线图上叠加均线、MACD 指标以及策略的买卖点标记就能很直观地看到策略在历史行情上是什么位置买、什么位置卖。我在实际使用中还发现一个 ECharts 图表的优势——交互刷新非常顺滑。你可以用鼠标拖拽缩放K线范围从看三年走势一路缩放到看最近半个月的走势缩放过程中均线、指标、买卖信号都会同步更新。这让复盘变得非常高效找到一个策略的典型买入点放大看当时的价格走势、指标形态理解策略为什么在那个位置发出信号。4.4 自定义策略开发像搭乐高一样组合信号前面说过OpenStock 的策略引擎做了接口化设计。写新策略其实不复杂核心就是起一个 Python 类实现两个方法信号生成根据数据计算产生买卖点和持仓管理确定当前应该持股还是持币。我举一个我自己写的策略例子组合了两个条件当收盘价站上20日均线且 MACD 柱线由负转正时买入当收盘价跌破20日均线或 MACD 柱线由正转负时卖出。这个策略本质上是在趋势跟踪的基础上叠加了一个震荡指标确认用来过滤部分假信号。运行回测后发现一个有意思的现象这个策略在上涨行情中表现很好能吃到大部分趋势但在震荡市里依然会产生不少无效交易反复止损。这说明任何技术指标都逃不开市场环境的影响没有“放之四海而皆准”的策略。也正因如此在自己搭的平台上反复测试策略的不同组合和参数就成了最有价值的日常操作。5. 部署后的常见问题与避坑经验运行这套系统一段时间之后我总结出几个高频问题的排查方法基本都是自己踩过坑才积累下来的经验。5.1 数据源连接失败怎么办这是最常见的问题也是第一个容易劝退新手的问题。现象是采集任务启动后直接报错日志里显示连接被拒绝或超时。先排查网络层——数据源地址是否可达。使用 curl 命令直接请求数据源接口看返回是否正常如果 curl 都不通要么是地址配错了要么是上游不稳定。再排查认证配置——有些数据源需要 token 或密钥检查 .env 环境变量里有没有配置完整。最后排查频率限制——短时间内频繁请求会被临时封禁这种情况下就需要给采集任务增加触发间隔不要在分钟级时间内反复请求。5.2 数据空洞和缺失值运行几天后发现某只股票的数据在某几天是空的这是增量更新的典型问题。原因可能包括当天数据源还没更新完定时任务就跑完了股票停牌导致当天没有K线数据源本身存在偶发缺失。我的处理办法是写了一个简单的数据对账脚本每天定时检查每只股票最近5个交易日的数据是否存在发现缺失就自动触发增量回补。这个脚本不大几十行代码但省去了每天手动检查的麻烦推荐复制这个思路作为系统后续的一部分。5.3 回测结果与预期严重不符回测结果看起来离谱大概率不是策略逻辑错了而是规则设置有问题。我的经验是从这三个方向依次排查第一手续费和滑点是否设置合理——很多人回测时忽略这一点导致回测收益率虚高实盘却赚不到钱第二涨跌停限制是否考虑——A股有10%/20%的涨跌停制度回测里如果允许在涨停价买入、跌停价卖出结果就会失真第三K线数据是否用了正确的复权方式——用前复权数据做回测策略信号会更贴近实际可交易价格。5.4 系统资源占用与性能优化数据库越跑越大、数据量越来越大以后查询速度会明显变慢这是所有个人系统的宿命。先从数据库层面优化——建立股票代码和时间字段的复合索引查询从全表扫描变成索引定位速度快很多。再定期清理低频访问的分钟数据我就设置了脚本只保留最近一个月的分钟K线更早的数据压缩为日K线即可。一个几千万行的数据表做好索引和分级存储后普通查询依然可以做到毫秒级响应完全够个人使用。写在最后的一点体会搭建并运行一套属于自己的股票数据平台带给我的不仅是技术上的成长更是思维方式上的改变。以前我用行情软件时看到的是别人处理好的数据和图表现在我用自己搭的系统看到的是数据从源头到终端的全过程——什么数据是可得的、成本是什么、质量怎么保证、每一步意味着什么。也许你会说市面上的工具那么多为什么要费劲自己搭一套我的回答是工具能给你答案但不会给你理解。自己搭平台的意义不在于你有了一套更好用的软件而在于你完整地经历了“数据→信息→信号→决策”的全链路。这种掌控感是任何一个现成工具都给不了的。如果你也想动手试试我建议从最简化开始——先部署起来、拉少量数据、跑通链路。不要一上来就想着写复杂策略先把地基打好后面一切都水到渠成。OpenStock 只是一个起点真正有意思的事情在前方等着你自己去探索。