1. 数据源选型的现实与妥协为什么一个搞Python的绕不开同花顺聊一个很实际的问题。但凡你用Python做股票相关的数据研究第一周大概率会把主流的免费数据源挨个试一遍。tushare老版本要攒积分新版Pro直接按积分档位卡权限日线入门没问题可一旦想取资金流、龙虎榜、财务附注这种细颗粒数据门槛一下子上来。baostock干净、稳定但覆盖面偏窄缺的东西太多。akshare一直在更新确实省事但它本质上是把各种网页接口包了一层你依然不知道背后的数据到底是从哪个口子出来的出了字段变动只能干等库更新。这种情况下同花顺系的数据接口几乎是绕不开的选择。原因不复杂同花顺作为老牌行情交易软件它的数据链路覆盖行情、财务、资金、板块、资讯几乎你能想到的日频和日内数据它都有现成的结构。更关键的是它很多Web端数据接口并不强制要求登录和token用Python直接请求能拿到相当完整的JSON数据这对个人开发者来说是巨大的成本优势。当然我要先说明白同花顺官方是有正儿八经的商用数据接口的比如iFinD那套东西需要机构账号个人基本不用想。我们平时在社区里讨论的“同花顺全数据接口”是指它的公开Web行情接口以及配合浏览器调试手段能拿到的数据结构。这套东西适合个人学习研究、本地策略回测不适合拿去商业化分发。这是边界问题心里要有数。我的建议是与其盲目装一堆第三方库不如先花半天时间把同花顺Web端的数据链路摸清楚。一旦你理解了它的请求规律后面不管接口怎么微调都能快速自我修复。这篇文章就是按这个思路来的——从环境准备开始带你把行情、资金、财务几类常用数据都跑通最后再讲稳定运行和排查问题的经验。2. 环境准备与接口认知先跑通第一次请求再说2.1 Python环境与依赖库安装先说环境。国内网络环境下的Python安装有时候会让人卡住尤其是下载慢、装完pip还不能用的情况。我的建议是直接走官网下载安装包版本选3.9到3.11之间都行别追最新大版本有些依赖库的预编译包更新没那么快。装的时候记得勾选“Add Python to PATH”这一步能省掉后面大量“python不是内部或命令”的麻烦。装完之后用国内镜像源配置pip这一步是刚需pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple pip install requests pandas numpy这三个库是先头部队。requests用来发HTTP请求pandas做数据清洗numpy做计算。等后面需要批量抓取的时候再补concurrent.futures这种标准库就行都不用额外装。如果你打算从同花顺的某些加密JS参数里抠header字段可能还需要一个执行JS的环境比如pyexecjs或py-mini-racer。但我个人经验是大多数行情接口的请求头可以用固定模板解决不需要实时执行JS只有遇到加密签名时才需要。这个后文会细说现阶段先不用装。2.2 同花顺Web数据接口的基本结构很多初学者最大的问题不是不会用Python而是不知道该请求什么地址。这里分享一个通用方法论打开同花顺官网或行情中心页面按F12打开开发者工具切到Network面板然后操作页面上的功能——比如翻页、切换个股、切换行情周期——观察哪些XHR请求在返回数据直接把响应内容复制出来就是最真实的数据结构。我长期盯下来同花顺Web接口的数据返回格式高度统一绝大多数是JSON少量是JSONP包裹。响应里基本都有一个状态字段比如“status_code”或“error_code”为0时表示成功还有data节点里面是字典嵌套列表的结构。请求参数一般是code证券代码、type周期类型、amount数量这类风格清晰直白。第一次写请求代码时建议先带上完整的请求头再试。因为某些接口会校验Referer和User-Agent缺了直接返回403或空数据。import requests session requests.Session() session.headers.update({ User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Referer: https://q.10jqka.com.cn/, Accept: application/json, text/plain, */* }) url https://q.10jqka.com.cn/api/php/.../xxx/yyy params { code: 600519, type: day, } resp session.get(url, paramsparams, timeout10) print(resp.status_code) print(resp.text[:500])注意我上面给的是一个示意路径实际接口地址会随版本变化。你真正要掌握的是用F12去找到当前可用的地址。这个方法比任何插件都可靠。2.3 先从一只股票的历史K线开始第一次完整跑通一个接口建议选历史K线。原因是它结构最标准验证最容易而且后续算因子、做回测都用得上。解析逻辑上不同接口的字段名可能不一样我建议写成字典映射不要硬编码索引。import pandas as pd def parse_kline(raw_list): df pd.DataFrame(raw_list) df.columns [date, open, high, low, close, volume, amount] for col in [open, high, low, close, amount]: df[col] pd.to_numeric(df[col], errorscoerce) df[volume] pd.to_numeric(df[volume], errorscoerce) df[date] pd.to_datetime(df[date]) return df.set_index(date).sort_index()第一次跑的时候大概率会遇到两类问题一类是响应里带了“symbol”之类的多余字段导致列数对不上另一类是成交量单位不统一有的接口返回手有的返回股。这些都是正常的说明你正在和真实世界的数据打交道按实际情况调整解析函数即可。总结一下这个阶段的重点不要急着写一个大而全的抓取框架先把“单个请求→解析→DataFrame”这个最小链路跑通确认数据准确再考虑批量。3. 行情数据实战实时快照、资金流与板块轮动3.1 实时行情快照的批量获取逻辑做日内监控和盘中选股靠的不是历史K线而是实时快照。所谓快照就是某一瞬间的价格、涨跌幅、成交量、五档盘口等数据。同花顺在个股详情页里会周期性请求这些信息接口返回的JSON通常包含“current_price”、“change_rate”、“volume_ratio”这类字段。自动盯盘时不要写死一个品种挨个去查那样太慢了。同花顺的Web接口基本都支持按“板块内多代码批量查询”一次请求可以传多个证券代码用逗号分隔返回的结果是一个列表每个元素对应一个代码。这个设计对个人用户非常友好请求次数直接降一个量级。我实测下来一次批量请求控制在50到80个代码以内比较稳妥超过容易触发超时或畸形响应。如果你要监控全市场5000多只票正确做法不是一次请求全传而是按市场板块分批拉。先拉“上证A股”、“深证A股”、“创业板”的成分列表再按批次取快照。板块成分列表本身也是个接口这样可以保证数据覆盖完整。关于频率纯人工盯盘不需要高并发一秒一次以内就够。即使做盘中因子计算5秒一次也差不多了。不要拿爬虫的思路去请求行情接口被限流之后恢复很麻烦。3.2 历史K线参数选择的经验历史K线接口里type字段的取值每家略有不同同花顺系的通常有“day”、“week”、“month”三档部分接口支持分钟级。我的建议是尽量在本地把日线数据做增量保存周线和月线由日线自己聚合生成不要每次都从接口去拉。为什么一是周线和月线接口的数据量虽然不大但重复请求没有任何意义二是自己聚合的K线复权逻辑是连贯的不会出现周线和日线口径不一致的问题。聚合方法用pandas的resample就能实现def resample_weekly(df: pd.DataFrame) - pd.DataFrame: weekly df.resample(W-FRI).agg({ open: first, high: max, low: min, close: last, volume: sum, amount: sum }) return weekly.dropna()注意我用了“W-FRI”这个对齐方式就是把周五作为一周的结束日。A股没有夜盘周五收盘就是一周定格这是国内行情数据聚合的基本常识。用默认的“W-SUN”会导致最后一个交易日被算到下一周去这是新手很容易踩的坑。3.3 资金博弈指标与资金流的计算口径这次的热搜词里有一条“同花顺资金博弈指标源码”说明很多人对资金流数据兴趣很大。同花顺客户端里的“资金博弈”指标核心思想是把成交单按大小分成主力、散户两个阵营红线代表主力资金净流入绿线代表散户资金净流出本质上是一个基于分笔成交数据的累计模型。用Python复现的逻辑不复杂。如果拿不到逐笔成交明细可以用分时成交接口近似处理。思路是读取当日分钟级别的成交量和成交均价用价格涨跌方向近似判断资金方向再按单笔金额大小做阈值切分。一个简化版的实现思路如下def estimate_main_force(df_minute, big_threshold100000): df df_minute.copy() df[direction] df[close].diff().fillna(0) df[direction] df[direction].apply(lambda x: 1 if x 0 else (-1 if x 0 else 0)) df[amount] df[volume] * df[close] df[net] df[amount] * df[direction] df[big_net] df[net].where(df[amount] big_threshold, 0) main_force_net df[big_net].sum() return main_force_net注意这只是一个示意性近似不是同花顺的精确算法。真正的资金博弈指标会用到委托方向、成交性质等更细的数据个人能拿到的公开数据很难完全一致。但作为策略因子这个方向是有效的——它捕捉的是大单驱动的净流入。3.4 板块行情与同花顺概念分类的抓取做轮动策略的人通常不会只看个股板块概念的热度更重要。同花顺的概念板块分类在Web端有现成的列表接口返回每个概念板块的涨跌幅、领涨股、总成交额等字段。我抓板块数据时通常两个维度结合看一是板块当日涨幅排名二是板块内个股的普涨程度上涨家数/总家数。后者比前者更真实因为少数权重股拉升也可以把板块指数拉红但那不代表板块整体强。这个指标可以用Python快速计算df[up_ratio] df[change_rate].apply(lambda x: 1 if x 0 else 0) 板块强度 df[up_ratio].mean()结合板块热度排名和内部强度基本能过滤掉大多数“虚涨”板块。这个思路放到任何一家行情数据源都适用不局限于同花顺。4. 基本面数据的获取F10资料与财务字段的拼接方法行情数据解决的是“交易”问题基本面数据解决的是“选股”问题。同花顺的F10资料页里包含公司概况、财务摘要、主营构成、股东信息等Web端也能找到对应的JSON接口。4.1 F10财务摘要的接口与解析F10财务摘要接口的返回结构通常是一个多级字典按报告期分组。比如每年的年报和季报每个报告期下有营收、净利润、ROE、毛利率等字段。解析的时候建议转成“宽表”即每一行是一个报告期每一列是一个财务指标。def flatten_financial_report(meta_list): records [] for item in meta_list: report_date item.get(report_date) data item.get(data, {}) record {report_date: report_date} for k, v in data.items(): record[k] v records.append(record) df pd.DataFrame(records) return df财务数据单位是个大坑。有些字段单位是万元有些是元还有些是百分比的小数形式。我建议在第一次清洗时统一做好单位转换并把字段名规范成自己习惯的英文命名后面写因子计算会舒服很多。4.2 股本变动与除权除息数据的对齐做财务数据和行情数据拼接的时候有一个非常容易被忽略的隐藏问题股本变动。如果一只股票在报告期内实施了送转股或者增发它的总股本变了那每股收益、每股净资产这些指标在相邻报告期之间就不可直接比较。同花顺的F10数据里通常包含“股本结构”或“分红扩股”栏目可以拿到具体的变动日期和变动原因。使用上我的经验是算同比增长率时注意用“单季度数据”而不是直接用累计数硬比。比如三季报的累计净利润同比对比也应该是去年三季报的累计数而不是去年年报数。这个逻辑写错了整条选股因子的可信度就崩塌了。4.3 防止财务数据里的ST和上市不足次新股污染样本财务数据拼接好之后还有一道过滤工序不能省。ST股票因为连续亏损财务指标和股价往往异常不排除它们会对因子测试产生极端干扰。上市不足60个交易日的次新股因为没有完整的历史数据也不适合放进回测样本。df df[~df[stock_name].str.contains(ST)] df df[df[list_days] 60]这两句话看着简单但能极大改善回测结果的质量。真实做研究时脏数据对结论的影响往往比模型本身更大。5. 数据完整性与口径对齐最容易翻车的环节5.1 前复权、后复权和不复权到底怎么选在本地保存行情数据时最让人头疼的问题就是复权。同花顺接口一般提供前复权和后复权两种计算结果。我的建议是本地原始行情统一保存不复权数据需要复权的时候再用复权因子自己计算。为什么这么干因为前复权数据是动态的——每次发生新的除权除息历史价格都会被重新调整之前保存的数据就“过期”了。如果你每天增量保存前复权数据在除权日之后你会发现自己数据库里的历史价格和接口返回的对不上越积越乱。不复权数据则永远是那个原始价格任何时候重新计算复权因子都能还原。复权因子的计算逻辑也不复杂。以除权日和除权价为锚点后复权因子是逐日连乘出来的前复权只是后复权整体缩放。代码示意factor (1 送转比例 每股分红 / 除权前收盘价)实际操作中用pandas计算也很快关键点在于记录每次除权除息的日期和方案。把这些信息存成本地表每次要复权时重新生成一次就好了。5.2 停牌日期空缺的填充逻辑A股市场经常有停牌短的一天长的半年。行情接口对停牌日的处理方式不一有的直接不返回该日数据有的返回0成交量。如果你用pandas的to_datetime做索引然后去rolling算均线停牌空缺会导致窗口错位必须显式地补全交易日序列。正确做法是用同花顺的交易日历数据生成一个完整的交易日序列然后left join行情数据缺失的成交量填0价格用前值填充或直接保留NaN。用NaN表示停牌比填0更安全因为很多指标公式里0会被当成真实的价格参与计算。df df.reindex(trade_calendar) df[close] df[close].fillna(methodffill) df[volume] df[volume].fillna(0)5.3 接口返回字段频繁变动的应对策略Web接口不是稳定不变的REST API随时可能调整字段名或返回值结构。应对方法不是抱怨而是写一层适配器。我在实际项目里会定义一个规范的内部数据结构所有外部数据都先转换成内部结构再做后续处理。这样外部接口变动时只需要改适配器这一层其他业务代码完全不用动。另外强烈建议做数据缓存。每次拉取K线都直接落到本地SQLite或Parquet文件下次请求前先查本地时间戳当天数据就直接用本地。既能缓解接口压力也能在接口异常时保证研究进程不中断。我用的是SQLite单文件、无服务、随时查询非常符合个人量化研究的场景。6. 批量抓取与性能优化代码跑得慢不一定是接口的锅6.1 多线程的正确打开方式单线程逐个请求1000只股票每个请求0.3秒加起来就是5分钟。虽然也不是不能用但如果你每天要抓全市场日线、财务摘要、资金流三套数据那就得几十分钟起步了。这时候需要并发。Python里我习惯用concurrent.futures的ThreadPoolExecutor。它比手动写threading简单又比multiprocessing省内存。行情接口本身就是IO密集线程池正合适把请求函数传给executor.map就行from concurrent.futures import ThreadPoolExecutor, as_completed def fetch_stock(code): data get_kline(code) return code, data with ThreadPoolExecutor(max_workers8) as pool: futures [pool.submit(fetch_stock, c) for c in stock_list] for fut in as_completed(futures): code, data fut.result() save_to_sqlite(code, data)6.2 并发数与频率控制的平衡并发不是越大越好。接口服务端通常有限流策略请求太频繁会触发封禁。我实测下来8个线程、每次请求间隔控制在0.2秒到0.5秒之间是比较稳的组合。全市场股票半小时内就能抓完也不会触发异常。要注意的是如果同一个接口同时开太多线程很快会收到签名校验失败或者直接超时的响应。这是服务端的保护策略不是你的代码写错了。遇到这种情况退避重试就行不要硬刚for retry in range(3): try: resp session.get(url, paramsparams, timeout10) data resp.json() break except Exception as e: time.sleep(1 * (retry 1))6.3 用增量更新替代全量更新数据抓全一次之后后续就不要再做全量更新了。每天的增量更新只需要拉最近5个交易日的K线、当日快照和当日资金流数据量小请求快对接口也友好。增量更新的核心是记录每个代码的本地最新日期然后从这个日期往后请求。注意在周末或节假日之后最新日期和当前日期之间可能隔着多个交易日增量更新时不要把区间写死为“昨天”最好动态计算。我看到很多人写爬虫框架时把重心放在并发和反爬上却忽略了“任务调度”本身。建议把更新任务写成可断点续跑的每次完成的代码记录到一个状态表里中途挂掉后重启只跑未完成的。这个小设计在实盘监控场景中能帮你省很多事。7. 常见报错排查与长期稳定运行建议7.1 高频报错场景对照这里把我在实操中遇到的、以及辅导别人时常见的报错做个汇总方便你排查时对号入座。现象最可能原因解决方向返回403或302缺少Referer或Cookie补全请求头必要时先用浏览器登录一次返回JSON但data为空列表参数名或证券代码格式错误用F12实际请求观察参数拼写部分代码返回成功部分失败临时停牌或退市整理期个股无数据捕获异常记录失败的代码到失败清单响应里出现签名或加密字样接口启用了JS签名校验降低请求频率改用符合条件的接口请求超时本地网络或接口负载高设置重试机制超时时间合理放大字段key不存在报KeyError接口字段变更或数据确实缺失用dict.get方法代替直接索引7.2 用日志记录代替print调试抓取程序一旦开始跑控制台print的信息稍纵即逝。强烈建议用logging记录运行状态包括每次请求的代码、耗时、返回状态。这样出了问题才能定位是哪个代码、哪个步骤导致的。import logging logging.basicConfig( filenamecollector.log, levellogging.INFO, format%(asctime)s %(levelname)s %(message)s )日志的另外一个作用是帮你发现“没有报错但数据不对”的隐性bug。比如某天你发现成交量突然少了翻日志才发现是接口单位变了。这类问题只有日志能帮你还原现场。7.3 长期维护的几个关键习惯数据抓取是个长期工程运行稳定半个月不难难的是连续跑半年一年不出问题。我总结几个实用习惯第一每两周做一次接口探活。随便取一两个代码请求一下核心接口确认返回正常。不正常的接口尽早发现尽早调整。第二本地数据库定期备份。SQLite数据库直接拷贝文件就行每天备份一次保留最近7份基本就不会丢数据。第三代码里所有接口地址不要硬编码散落各处集中放在配置文件里。改接口时只改一处方便快捷。关于同花顺“全数据接口”这件事可行的路径其实是组合式的——行情走行情接口财务走F10数据源资金流用分钟数据进行估算。没有哪一个接口能包揽所有但组合起来覆盖90%的个人量化研究需求是完全没有问题的。真正有价值的不只是拿到数据而是拿到干净、连续、口径一致的数据。这一篇里讲的解析规范、复权逻辑、停牌处理、增量更新本质上都是围绕这个目标。最后再补充一个很实用的小习惯每次新增一种数据字段先在本地写一个最小验证脚本打印几条样例数据人工核对一遍再纳入正式的抓取流程。数据采集这种事处理脏数据的功夫往往比抓数据本身还要大但这也是一个数据研究者必要的基本功。