自托管开源行情监控系统OpenStock搭建指南：从数据采集到Docker部署

如果你也有过这种想法——把感兴趣的那批股票行情数据按自己的节奏存下来，自己写指标、自己做提醒，而不是每天打开好几个App翻来翻去——那OpenStock这套自托管的开源行情监控系统值得你花一个下午把它搭起来。OpenStock定位很简单：它不是一个又一个现成的炒股软件，而是一套跑在你自己的服务器或者本地电脑上的数据管道，把行情采集、入库、展示、告警全部串起来，数据是你自己的，规则也是你自己的。这篇文章我按自己实际搭建过的路径来写，从环境准备到抓数据，从定时任务到Docker部署，每一步都给可复现的命令和配置。适合对Python和Linux有一点点基础、想把行情数据抓在自己手里的折腾型选手；就算你是纯新手，只要照着做也基本能跑通。

1. OpenStock到底解决什么问题

1.1 自建行情系统的核心价值

很多人一开始会问：我用同花顺、东方财富、雪球不就够了，为什么还要自己搭一套？这句话本身没错，如果你只是每天收盘后瞄一眼持仓，现成App体验确实更好。但OpenStock要解决的从来不是“看行情”这个动作，而是“数据资产归属”的问题。

现成的行情软件有几个天然痛点。第一，历史数据你导不出去，想算个三年回测，K线还得自己一份份抠；第二，筛选逻辑和提醒规则都是别人定义好的，你想找一个“连续三天缩量且收盘价站上20日均线”的标的，在App里基本做不了；第三，数据粒度不够灵活，有些场景你需要分钟级数据、需要复权后的价格序列，App给的往往是一份“高度包装”的结果。

OpenStock的价值在于，它把数据采集层、存储层、展示层和告警层都拆开，全部跑在你自己的环境里。你拉下来的每一根K线、每一条企业基本信息，都落在你自己的数据库里。你可以写任意指标、做任意切片，甚至把数据喂给其他量化框架。用一句话概括就是：主流系统给你“鱼”，OpenStock给你“渔”的整套工具链。

1.2 它和券商App、行情网站的本质区别

区别其实在“架构”而不在“功能”。券商App是中心化服务，服务器在对方那边，数据权限完全由对方决定，哪天接口关了、规则改了，你的数据颗粒度就得跟着变。OpenStock是自托管架构，代码在GitHub上，数据源是公开行情接口，采集逻辑在你手里，数据落在你自己的磁盘里。

这就带来三个实际好处。一是稳定性预期不同：免费接口偶尔波动，但你的采集程序有重试机制、有数据补偿，整体数据链路是可控的。二是分析能力不受UI限制：你可以用Python直接连数据库跑pandas，也可以用前端页面做可视化，数据打通后玩法完全由你定。三是学习价值极高：一套完整的行情系统涉及定时调度、API封装、数据库设计、前端图表渲染，哪怕不碰股票，把它当成一个全栈项目来做也值回时间。

当然有一个前提我必须说清楚：OpenStock是一套技术基础设施，不是投资决策工具。它里面跑的告警、指标、涨跌幅排序都只是数据结果，不构成任何投资建议。如果你抱着“搭完就能跟着提示赚钱”的心态，建议趁早调转方向。

2. 搭建前的环境规划与选型逻辑

2.1 主机与操作系统选型

先说一个最实际的问题：OpenStock跑在什么机器上？实践下来有三类选择，取决于你的使用强度。

第一类：本地电脑。Windows、macOS、Linux都行，适合开发调试和只盯几十只股票的场景。本地跑的优势是零成本，缺点是不能7x24小时开机，盘中盯盘和定时任务会受断电、休眠影响。第二类：云服务器。2核4G内存、20G硬盘左右的入门机型就能带起来，适合长期运行。注意选网络稳定一点的厂商，行情抓取对网络质量有一定要求。第三类：树莓派或者NAS上的Docker。这类设备功耗低，适合放家里长期跑，但要注意存储别用SD卡，容易损坏数据库文件。

操作系统我推荐Debian系的Linux发行版，比如Ubuntu 22.04 LTS。理由很简单：Docker支持最成熟、Python环境干净、Nginx配置资料多。Windows也能跑，但坑不少，比如路径分隔符、编码、计划任务，每个都要单独处理。

注意：如果完全没接触过Linux，建议先在本地虚拟机上练习一遍，再用云服务器正式部署。别直接在生产机器上边学边操作，容易把环境弄乱。

2.2 核心依赖清单

OpenStock的典型技术栈由以下组件构成：Python负责数据采集和接口服务，Node.js负责前端构建，Docker负责统一打包，Nginx负责反向代理。下面这张表是我搭建时实际使用的版本和用途，按依赖顺序排列：

除了运行时依赖，Python侧还需要几个关键库：FastAPI作为Web框架，SQLAlchemy做ORM，APScheduler做定时任务，AkShare作为行情数据抓取库，pandas做数据处理。这些都会在requirements.txt里统一声明，后面我会给出具体安装步骤。

2.3 数据库选型：SQLite还是PostgreSQL

OpenStock在数据库设计上做了兼容，支持SQLite和PostgreSQL两种后端，配置切换只改一行连接串就行。那到底怎么选？我给出的标准是看“数据量”和“写入并发”。

如果只是跟踪沪深两市几千只股票做日线级别数据，数据量也就每天几千行，一年下来不到百万行，SQLite完全扛得住。它的好处是零运维，一个文件就是整个数据库，备份直接拷贝文件，适合个人使用。

但如果你要存分钟级K线，或者打算长期积累五到十年行情数据，写入量会大很多。分钟级数据每周就几十万行，这时候SQLite单文件写锁的问题会逐渐暴露，读和写互相阻塞。这种情况建议直接用PostgreSQL，它在高并发写入和多条件查询上明显更从容。

数据库表结构方面，OpenStock有三张核心表：股票基础信息表（stock_basic）、行情日线表（daily_quote）、告警记录表（price_alert）。以下是简化的建表逻辑：

CREATE TABLE stock_basic ( id SERIAL PRIMARY KEY, code VARCHAR(10) UNIQUE NOT NULL, name VARCHAR(32) NOT NULL, industry VARCHAR(32), list_date DATE ); CREATE TABLE daily_quote ( id SERIAL PRIMARY KEY, code VARCHAR(10) NOT NULL, trade_date DATE NOT NULL, open NUMERIC(10, 3), close NUMERIC(10, 3), high NUMERIC(10, 3), low NUMERIC(10, 3), volume BIGINT, amount NUMERIC(16, 2), UNIQUE(code, trade_date) );

daily_quote里的UNIQUE(code, trade_date)约束很关键，这是数据去重的兜底方案，后面抓数据章节你就能体会到它的用处。

3. 源码获取与前后端初始化

3.1 获取OpenStock源码

OpenStock的源码托管在GitHub上，仓库名就叫OpenStock。打开终端，克隆代码到指定目录：

git clone https://github.com/openstock/openstock.git cd openstock

克隆完成后，看下目录结构。一个规范的开源项目会明确分好前后端和部署文件，通常长这样：

openstock/ ├── backend/ │ ├── app/ │ │ ├── api/ # 接口路由 │ │ ├── models/ # ORM模型 │ │ ├── services/ # 业务逻辑 │ │ ├── collectors/ # 数据采集器 │ │ └── main.py # 后端入口 │ ├── requirements.txt │ └── .env.example ├── frontend/ │ ├── src/ │ ├── package.json │ └── vite.config.js ├── docker/ │ ├── Dockerfile.backend │ ├── Dockerfile.frontend │ └── docker-compose.yml └── README.md

我建议优先clone最新的release标签，而不是直接拉main分支。因为main分支可能处于功能迭代中，偶尔会有临时改动影响稳定性。release版本通常是发布前测试过的，对第一次搭建的朋友友好得多。等跑通了再切回main体验新功能不迟。

3.2 后端配置与依赖安装

后端基于Python，第一步是创建虚拟环境，避免依赖冲突：

cd backend python3 -m venv venv source venv/bin/activate pip install -r requirements.txt

requirements.txt里包含前面提到的FastAPI、SQLAlchemy、APScheduler、AkShare等库。安装过程可能需要几分钟，如果网络环境不好，建议配置国内pip镜像源加速。

安装完成后，需要初始化环境变量。项目里提供了一个.env.example文件，复制为.env然后按需修改：

cp .env.example .env

.env里最重要的几个配置项如下：

# 时区，影响K线日期和告警时间判断 TIMEZONE=Asia/Shanghai # 数据库连接：SQLite或PostgreSQL DATABASE_URL=sqlite:///./openstock.db # DATABASE_URL=postgresql://openstock:password@localhost:5432/openstock # 行情数据源：akshare / sina / tencent DATA_SOURCE=akshare # 抓取失败重试次数 FETCH_RETRY=3 # 告警通知地址（可留空） SERVER_CHAN_KEY= DINGTALK_WEBHOOK= SMTP_HOST= SMTP_USER= SMTP_PASSWORD=

我踩过一个坑是忘记改时区。默认的UTC会导致K线日期和交易日历错位，数据存进去都是前一天或后一天的时间，前端展示曲线看起来总怪怪的。建议第一时间把TIMEZONE固定为Asia/Shanghai。

初始化数据库结构，项目使用Alembic管理迁移：

alembic upgrade head

3.3 前端构建与本地开发服务器

接下来是前端。OpenStock的前端基于Vue 3和Vite构建，图表用的是ECharts，整体交互比较轻量。

cd ../frontend npm install

npm install的耗时取决于网络情况，如果公司在用私服或者网络受限，设置好registry镜像就行。依赖装完，可以先启动本地开发服务器试试：

npm run dev

默认端口是5173，浏览器打开就能看到前端页面。这时前后端还没对接，页面会提示API请求失败，先不用管，等后端也启动就好。

前后端分离是现在主流做法，看起来多了一道构建步骤，实际很划算。前端只管渲染和交互，后端只出JSON接口，两者通过HTTP通信。调试的时候一个浏览器标签页开前端DevServer，一个开后端Swagger文档，两边互不干扰，改前端不用重启后端，效率高很多。

启动后端开发服务器的方式是：

cd backend uvicorn app.main:app --reload --port 8000

后端起来后，访问http://localhost:8000/docs能看到FastAPI自动生成的接口文档，能直接测试行情查询、自选股管理等接口。前端要联调后端，只需要在Vite配置文件里设置代理，把/api前缀代理到8000端口。

4. 行情数据源接入与抓取策略

4.1 常见免费数据源对比

OpenStock的数据采集层是插件化设计的，默认支持多个数据源。我实际用过的有三类：AkShare聚合接口、新浪财经接口、腾讯财经接口。它们的对比如下：

先说结论：日常跑日线行情，用AkShare是最省事的。它对新浪、东财等公开接口做了统一封装，你不需要关心具体请求URL和参数格式，直接拿Python函数调用就行。但要注意，AkShare本质是聚合库，上游接口一旦调整，它也可能跟着变动。所以OpenStock里我做了一层抽象，不直接绑死某个源。

4.2 构建统一抓取接口

为了避免业务代码被数据源细节污染，采集层设计了一个基类：

# backend/app/collectors/base.py from abc import ABC, abstractmethod from datetime import date class BaseQuoteCollector(ABC): @abstractmethod def fetch_daily_quote(self, code: str, start_date: date, end_date: date) -> list[dict]: """获取日线行情""" @abstractmethod def fetch_stock_list(self) -> list[dict]: """获取股票基础列表"""

AkShare的实现长这样：

# backend/app/collectors/akshare_collector.py import akshare as ak import pandas as pd from .base import BaseQuoteCollector class AkshareCollector(BaseQuoteCollector): def fetch_daily_quote(self, code: str, start_date: date, end_date: date) -> list[dict]: df = ak.stock_zh_a_hist( symbol=code, period="daily", start_date=start_date.strftime("%Y%m%d"), end_date=end_date.strftime("%Y%m%d"), adjust="qfq" ) records = [] for _, row in df.iterrows(): records.append({ "code": code, "trade_date": row["日期"].strftime("%Y-%m-%d"), "open": row["开盘"], "close": row["收盘"], "high": row["最高"], "low": row["最低"], "volume": row["成交量"], "amount": row["成交额"], }) return records

只要实现同一个接口，多数据源就可以随时切换。今天用AkShare跑，明天换成新浪，配置文件里改一行DATA_SOURCE=sina就完事。这种设计看起来多花了一点抽象成本，实际运维时能救你于水深火热之中——免费接口说变就变，需要备用源的时刻迟早会来。

4.3 请求频率控制与数据去重

免费行情源最大的隐形规则是“别把人家打挂了”。A股五千多只股票，如果不做控制，几分钟就能把日K全量拉一遍，很容易触发临时封禁。OpenStock在采集层内置了限速器，用最简单的令牌桶思路实现，保证每秒最多N次请求：

# backend/app/collectors/rate_limiter.py import time import threading class RateLimiter: def __init__(self, max_calls_per_second=2): self.min_interval = 1.0 / max_calls_per_second self._lock = threading.Lock() self._last_ts = 0.0 def wait(self): with self._lock: now = time.time() wait_time = self.min_interval - (now - self._last_ts) if wait_time > 0: time.sleep(wait_time) self._last_ts = time.time()

初次全量抓取时，我建议用每秒1到2次的速度慢慢跑，五千只股票大概需要四十多分钟到一小时。这个速度虽然慢，但胜在安全。之后每天增量更新只需要拉当天的行情，几百个请求一会儿就跑完了。

数据去重同样重要。daily_quote表里的联合唯一约束已经能兜底，但代码层也要做好判断，避免重复请求浪费流量。我采用的策略是“先查库再抓取”：对每个股票，在抓取前查一下库里已有的最新交易日，只抓最新日期往后的数据。这样既能完成增量更新，又能确保断点续跑时不重复劳动。

4.4 数据清洗与复权处理

行情数据抓下来，不能直接入库。原始数据常见的问题有几个：除权日价格断层、停牌股成交量缺失、个别接口返回字符串类型数值。这些都会影响后续分析的质量。

复权处理是最需要重视的。股票分红送股后，价格会突然跳空，不复权的话K线图上会留下一个假缺口。OpenStock支持前复权和后复权两种口径，实际使用时我推荐历史回测统一用后复权。原因很简单：后复权是以股票上市首日价格为基准，把所有分红送股都累加回去，历史价格曲线是连续的，计算收益率时直接拿后复权价格做差即可，不会因为区间不同产生口径偏差。

清洗逻辑的伪代码如下：

def clean_quote(record: dict) -> dict: # 过滤停牌或无效数据 if record["volume"] is None or record["volume"] == 0: return None # 数值类型处理 for field in ["open", "close", "high", "low"]: record[field] = float(record[field]) record["volume"] = int(record["volume"]) record["amount"] = float(record["amount"]) if record["amount"] else 0.0 return record

我在实际抓取中发现，停牌日的成交量返回的数据形态不统一，有的返回0，有的返回空字符串，有的直接缺行。统一在清洗阶段处理掉，数据库里的数据质量才能保证。

5. 定时任务、异动告警与通知

5.1 定时调度设计

OpenStock作为自托管系统，一旦部署到服务器上，就得可靠地按天运行。定时调度我选用APScheduler，它的CronTrigger和Linux crontab语法接近，上手成本低，而且可以直接嵌入FastAPI进程，不用额外起一个独立的调度服务。

核心配置如下：

from apscheduler.schedulers.background import BackgroundScheduler from apscheduler.triggers.cron import CronTrigger def init_scheduler(): scheduler = BackgroundScheduler(timezone="Asia/Shanghai") # 每天15:10抓取当日日线数据，等交易所收盘清算完 scheduler.add_job( job_daily_fetch, CronTrigger(day_of_week="mon-fri", hour=15, minute=10), id="daily_fetch", replace_existing=True, ) # 每5分钟检查一次告警规则 scheduler.add_job( job_alert_check, CronTrigger(day_of_week="mon-fri", hour="9-15", minute="*/5"), id="alert_check", replace_existing=True, ) scheduler.start()

时间点选择是有讲究的。A股15:00收盘，15:10抓数据比较合适，既能覆盖清算后的最终结果，又不会因为过早请求而拿到不完整的数据。盘中检查告警频次我设为5分钟，这个粒度对个人玩家足够了，抓太频容易给免费数据源增加压力。

我自己实际还遇到一个情况：程序因为网络问题挂了一会儿，等恢复时会发现当天定时任务没有执行。为此我准备了一个启动补偿函数，在每次启动时检查当天数据是否已抓取完成，没完成就立刻补抓。这类“自愈”机制对长期运行的小系统很重要。

5.2 自选股异动告警

告警功能是OpenStock的另一个重头戏。它的核心思想很简单：给自选股配置一组规则，当实时或收盘数据满足条件时，触发通知。规则以JSON配置存储，不用改代码就能加新规则。

一个典型的告警规则配置长这样：

{ "name": "放量上涨监控", "enabled": true, "scope": ["600519.SH", "000858.SZ"], "conditions": { "change_pct": { "gt": 5.0 }, "volume_ratio": { "gt": 2.0 } }, "notify_channels": ["serverchan", "dingtalk"], "cooldown_minutes": 60 }

cooldown_minutes字段特别说一下，官方叫“冷却时间”。如果没有它，某只股票在一个小时内持续触发条件，你可能会收到十几条相同推送，手机直接被打爆。加上冷却时间后，同一标的发生相同规则，只推送一次，等过了冷却窗口才会再次触发。

5.3 通知渠道接入

OpenStock支持三种通知渠道：Server酱、钉钉机器人、SMTP邮件。三者的接入方式差异很大。

Server酱是个人消息推送服务，绑定微信后，通过一个Webhook就能把消息推送到手机微信。它最大的优点是接入简单，只要在配置里填一个Key即可，是我个人最喜欢的渠道。

钉钉机器人需要先在钉钉群里添加自定义机器人，获得一个Webhook地址。请求体是JSON格式：

curl -X POST 'https://oapi.dingtalk.com/robot/send?access_token=你的TOKEN' \ -H 'Content-Type: application/json' \ -d '{ "msgtype": "text", "text": { "content": "OpenStock告警：600519.SH 涨幅5.2%，成交量放大2.3倍" } }'

SMTP邮件是最后的兜底方案，但我不太推荐作为主力通知渠道，因为邮件容易进垃圾箱，而且推送延迟不可控，盘中告警的意义会打折扣。

通知渠道的优先级我建议这样排：Server酱或钉钉走实时推送，邮件只做每日摘要。比如每天收盘后推送一份“今日行情概览”邮件，记录哪些股票触发了规则，既给了完整记录又不会过度打扰。

6. 部署上线：Docker容器化与反向代理

6.1 用Docker Compose编排整套服务

本地开发跑通后，正式部署我强烈建议用Docker Compose，把后端、前端、数据库全部容器化。这样做最大的好处是环境一致性，换一台服务器不会有“在我机器上明明是好的”这种问题。

项目里已经提供了生产用的docker-compose.yml，内容大致如下：

version: "3.8" services: backend: build: context: . dockerfile: docker/Dockerfile.backend env_file: - backend/.env volumes: - openstock-data:/app/data restart: unless-stopped ports: - "8000:8000" frontend: build: context: . dockerfile: docker/Dockerfile.frontend restart: unless-stopped nginx: image: nginx:1.24-alpine ports: - "80:80" - "443:443" volumes: - ./docker/nginx.conf:/etc/nginx/conf.d/default.conf - ./certbot/www:/var/www/certbot - ./certbot/conf:/etc/letsencrypt depends_on: - backend - frontend restart: unless-stopped postgres: image: postgres:14-alpine environment: POSTGRES_USER: openstock POSTGRES_PASSWORD: change_me POSTGRES_DB: openstock volumes: - openstock-postgres:/var/lib/postgresql/data restart: unless-stopped volumes: openstock-data: openstock-postgres:

后端容器里跑的是uvicorn服务，同时由supervisor管理APScheduler定时任务，保证两个进程都能存活。前端容器构建的时候会把Vue打包成静态文件，由Nginx统一托管。

启动命令非常简单：

docker compose up -d --build

在项目根目录执行这条命令，Compose会依次构建镜像、启动容器。第一次构建较慢，因为要拉基础镜像和安装Python/Node依赖，之后增量构建就快很多。

6.2 Nginx反向代理与HTTPS

容器起来后，所有服务都绑定在Docker内部网络，外部只暴露Nginx的80和443端口。Nginx配置里需要注意两点。

第一，前端静态资源和后端API要区分路由。前端打包产物放在/usr/share/nginx/html，后端接口走/api前缀，反向代理到backend容器。这样同一个域名既能访问页面也能访问数据接口，不需要额外开端口。

第二，HTTPS证书。现在申请免费证书很方便，推荐用Let's Encrypt。第一次手动申请，之后配置自动续期脚本就行。

server { listen 80; server_name stock.example.com; location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://backend:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

需要注意，很多免费接口对User-Agent和Referer有校验，而且proxy_pass后面的域名取决于Docker网络里的服务名。实际配置时，backend的地址要写成Docker Compose中的服务名backend，不要写localhost，这一点对新手特别容易踩坑。

6.3 数据备份策略

跑了半年后，你数据库里的行情数据会越来越珍贵，备份这件事必须提前做。我的实践是双保险：容器里用cron每天凌晨把PostgreSQL数据导出为SQL文件，然后同步一份到本机磁盘或对象存储。

docker compose exec -T postgres pg_dump -U openstock openstock > backup/openstock_$(date +%Y%m%d).sql

备份文件保留近30天，超过的自动清理。万一哪天误操作删了数据，直接导入备份文件就能恢复。我建议每季度手动验证一次备份能否正常恢复，别等真出事才发现备份文件是坏的。

7. 我踩过的坑与建议

7.1 时区问题导致K线错位

我在前面提过时区问题，这里展开说下具体症状。第一次部署时，我用默认的UTC时区运行，结果入库的trade_date比实际晚了8小时。日线级别还好，只是日期错位一天；但分钟级数据直接全乱——K线图上一根根柱子跟实际盘面完全对不上。

排查过程很简单，打开数据库查几条记录，对比接口返回的时间，一下子就发现了。解决办法也简单，在配置文件的数据库连接串里明确时区，在Python侧设置pytz.timezone("Asia/Shanghai")，同时在APScheduler启动时指定相同时区。三处统一后，问题彻底消失。这类坑非常隐蔽，排查一次后就记住了。

7.2 停牌股造成的数据异常

停牌股是另一个高发坑。某只股票停牌期间，当日K线要么缺行，要么返回成交量0但价格沿用上一交易日数据。如果后端直接拿原始数据算涨幅，会出现“明明停牌了却显示上涨5%”的怪相。

我的处理方案是在清洗阶段过滤掉volume == 0或trade_date为空的记录。同时，在告警模块里增加一条规则：当日无成交量的股票不参与任何涨幅计算。这样既保证了计算合理性，也避免误报。

7.3 免费数据源接口突然改动

运营了几个月后，大概率会碰到一件事：某个免费数据源突然调整了接口参数或字段名，抓取程序开始报错。AkShare这类聚合库通常是上游变了之后跟着发新版本，如果你锁了旧版本号，就得手动升级。

我的应对方式是组合拳。首先，采集模块保持多源冗余设计，主源挂了立刻切备用源。其次，给抓取任务加失败告警，只要连续N次失败就推送通知到手机，及早发现。最后，给周末留一个固定的“自检窗口”，批量把前五天的数据重抓一遍，用来弥补日常漏抓。

7.4 后续还能扩展什么

OpenStock跑顺以后，很多朋友会问我下一步能加什么。我自己的经验是可以从三个方向入手。一是指标计算层，在采集数据之上加MA、MACD、布林带等常用技术指标，存成独立表供前端绘图。二是市场热度统计，计算每日涨跌停数、涨停连板高度、成交额分布，生成一个简单的大盘情绪面板。三是接入模拟盘或paper trading，把告警规则直接对接模拟交易环境，验证自己的策略逻辑而不用真金白银。

这些扩展的共同前提是OpenStock已经把数据底座搭好了，剩下的只是自由发挥。数据在手，想怎么折腾都行。

最后再分享一个实际运营的小技巧：如果发现有时候行情数据出现零散缺失，不用急着全量重抓。可以写一个简单的补偿脚本，拉取最近10个交易日的数据，按联合唯一约束做“冲突忽略”插入。这样即能补上缺失的数据，又不会影响已经存在的正确记录。这样运行了半年下来，我的OpenStock数据库基本没有断档过，数据质量比我预想中要好得多。