简介：一套涵盖沪深股市自开市以来至2022年1月10日全部个股日线数据的SQL数据包，面向量化研究者、投资者与金融数据分析学习者，可支撑策略回测、技术指标验证、历史走势复盘及入门教学等应用场景。数据打包为单个RAR压缩文件，内含1个SQL文件，总容量约424.52MB，便于导入MySQL等主流关系数据库后直接进行SQL查询、统计与二次开发。字段除开盘价、收盘价、最高价、最低价、振幅、成交量、成交额、换手率外，还预计算了MACD（移动平均收敛/发散）、CCI（商品通道指数）及同花顺手机版多空指标，显著节省数据整理与技术指标计算时间，便于直接观察买卖信号与超买超卖状态。已有611人学习下载，适合需要高效获取长周期A股行情数据、构建预测模型或验证交易策略的用户，也可作为金融数据课程的分析样本，帮助快速上手结构化历史数据的处理与研究。
1. 沪深股票历史到2022-01-10的全部日线数据：先弄清楚这到底是个什么活
做策略回测或者复盘行情的时候，最尴尬的不是策略不赚钱，而是手里的数据经不起推敲：从行情软件导出的只有最近几百根K线，网上找的csv缺字段、缺停牌日，前后复权还不一致。标题里说的这件事，就是把沪深两市的全部股票，从各自上市首日开始，到2022年1月10日为止，把每天的OHLC、成交量、成交额、换手率这类日线数据完整拉下来，洗干净，存成一个本地数据仓库，让策略代码可以直接读。这不是一个下载脚本那么简单，它牵扯到复权方式、停牌处理、交易日历对齐、增量更新，以及最容易被忽略的数据版本问题。适合谁？给做量化回测的个人研究者、准备搭建本地行情基础设施的团队，以及想把历史数据作为研究底座的任何人。
2. 选型：全量日线的数据源怎么定才不返工
2.1 三条路线：手写爬虫、开源接口、商业终端怎么选
先想清楚数据从哪里来，再谈怎么写代码。这个标题的数据量不大不小：沪深两市五千只左右的股票，单票一天一行，从上市到2022年1月10日，全市场累计大约一千万行。这个体量不需要上分布式，一台普通电脑完全能处理，难点在数据源的稳定性和字段一致性上。
手写爬虫直接抓门户网站的行情接口，这条路我当年走过，适合练手，不适合生产。网页接口的参数名和返回结构经常变，反爬策略也会在批量请求时触发，更重要的是，不同来源的字段定义可能不一致，比如有的接口成交量是“手”，有的接口直接给“股”。如果你只验证一两天的数据大概率看不出问题，一旦跑全量，隔三差五就要回去修解析逻辑，时间成本远高于收益。
开源行情库是更常见的做法。用类似akshare的工具，把底层HTTP请求封装成统一的Python函数，一次拿一只股票的完整历史日线，返回的字段固定，还提供一个参数用来切前复权、后复权和不复权。不过要注意，这类库本质上是“网页接口的Python壳”，它不是某个官方数据源，接口名和返回结构会随着源站改动而变化。我的习惯是先固定版本，再写代码，否则半年后重新跑脚本，大概率要改字段名。
商业终端数据质量最好，但导出受限制，而且按接口计费，全市场全历史导出一次的成本不低。对个人研究者来说，开源接口加本地缓存是性价比最高的方案。下面是三条路线我实际体验的对比：
| 路线 | 数据完整性 | 维护成本 | 接口稳定性 | 适合场景 |
|---|---|---|---|---|
| 手写爬虫 | 取决于源站 | 高，源站一改就崩 | 低 | 练手、单票抓取 |
| 开源行情库 | 较高，需自己校验 | 中，升级需重测 | 中 | 全市场批量落地 |
| 商业终端 | 高 | 低 | 高 | 团队正式数据底座 |
如果你打算长期维护数据，我的建议是主线用开源行情库，另外留一个手工导出的csv作为抽查基准，不要直接跳过这一步。我的实际经验是：全量落库之后数据问题大多是静默的，没有一个参照基准，那些字段单位不一致、复权漂移的问题很难被发现，等策略回测结果出来了才怀疑数据有问题，那才是最难受的。
2.2 开源接口的边界：接口名会变，数据得自己验收
开源行情库解决的是“能拿到数据”的问题，不保证“数据是对的”。它把源站返回的json整理成DataFrame，但这个过程中不会帮你做数据质量校验。拿到的数据里停牌日就是缺失，新股上市首日可能有异常换手，除权日附近的成交量可能没有跟随复权调整。
调用前你要先确认三件事：第一，接口函数在你装的版本里还存在，名字有没有变；第二，返回字段有哪些，单位是什么；第三，接口对批量请求有没有频率限制。以日线接口为例，常见的做法是传入股票代码、起止日期，然后指定复权方式，返回的DataFrame里有日期、开高低收、成交量、成交额、振幅、涨跌幅、涨跌额、换手率。注意这里有一个非常关键的细节：当你不指定复权时，返回的是交易所原始报价，涨跌幅按原始报价计算；当你指定前复权时，那个历史价格会被后来的除权事件重算，已经不是你当年在行情软件里看到的价格了。这个差异，第4章会专门展开。
还有一个容易忽视的问题：接口返回的日期范围并不完全等于交易日，有些源站把集合竞价形成的开盘价也算进去，有些会漏掉某些半天的交易记录。所以在写批量脚本之前，先随机拿几只股票，用你信任的行情软件逐日核对，这个验收步骤省不掉。我一般会选一只老股票、一只次新股、一只长期停牌复盘的股票，分别核对，三种情况覆盖大部分数据坑。
2.3 交易日历与目标数据版本：先钉住“2022-01-10”这个快照
这个标题里的“到2022-01-10”是一个数据快照的概念，它背后有一个容易踩的坑：股票历史数据不是“静态”的，它会被新发生的事件改写。前复权数据尤其明显，只要某只股票在2022年1月10日之后又除权了一次，今天拉出来的2021年价格就和当时看到的不一样，因为前复权会把新的除权因子分摊到所有历史价格上。
所以做这个项目时，第一件事不是写下载脚本，而是定义清楚自己要的是“截至2022-01-10的行情快照”还是“2022-01-10之前的全部最新视角数据”。如果是前者，需要在脚本里固化一个version参数和目标日期，并且明确接受的复权方式是“不复权”或“后复权”，因为只有这两种方式下，历史价格不会因为未来事件而变化。前复权数据对回测有一个致命的隐患：样本里混入了未来信息，等于你的回测偷偷看了答案。
我建议的工程约定是：
提示：目标数据截止日为2022-01-10的项目，统一使用“不复权”或“后复权”作为存储基准，把前复权作为读取时的展示选项。这样历史价格是稳定可复现的，回测结果不会因为数据更新而漂移。
这个约定要求你在第3章的下载脚本里就把参数定死，避免同一批数据在多个版本之间来回换。
3. 全量下载落地：清单、接口与落盘的最小脚本
3.1 第一步：拉全市场A股代码清单
下载全量日线，第一步是拿一份完整的股票代码清单。这个清单要覆盖上交所和深交所的全部A股，包含股票代码、名称和上市日期。上市日期非常重要，它是你下载历史数据的起点——虽然你可以统一从1990年拉数据，但这样会多产生大量空请求，效率低。
先用开源行情库拿清单，保存成csv备用：
import akshare as ak import pandas as pd # 拉取全市场A股代码列表 stock_info = ak.stock_info_a_code_name() # 看一眼结构 print(stock_info.head(3)) print(stock_info.shape) # 本地存档，后续下载循环直接读这个文件 stock_info.to_csv("./data/stock_list.csv", index=False) # 用上市日期补全清单，部分接口可以返回上市日期 stock_list = pd.read_csv("./data/stock_list.csv") print(stock_list.columns.tolist())这段代码做的事就是把代码清单落盘，避免每次批量下载前都重新请求一遍。要注意，stock_info_a_code_name这个接口在部分版本里不返回上市日期，只有一个代码和名称的DataFrame。如果你拿到的清单没有上市日期，方案是：下载时发现返回空数据就跳过，或者把下载起点统一退回1990年再按数据是否存在来截断。
参数说明：这里没有做任何清洗，因为清单本来就是全量A股，包括ST、次新股和代码变更过的股票。不要提前按名称过滤ST或退市股，历史日线研究中这些样本往往是有用的。我建议用“代码”字段作为唯一键，不要用名称，因为名称会变，而代码在正常情况下稳定。
3.2 第二步：单只股票日线的最小调用
在跑全市场之前，先用一只股票把接口行为和返回字段摸清楚。这一步不要图快，因为后面所有批量流程都是围绕这个返回结构来写的。以日线接口为例，最小调用大概是这样的：
import akshare as ak import pandas as pd symbol = "000000" # 示意代码，换成你要测试的实际六位代码 # 拉取不复权日线 df = ak.stock_zh_a_hist( symbol=symbol, period="daily", start_date="19900101", end_date="20220110", adjust="" ) print(df.dtypes) print(df.head(3)) print(df.tail(3)) print(f"行数: {len(df)}")这段代码传了四个参数：period固定为daily表示日线；start_date写19900101，保证能覆盖到沪深两市最早上市股票的起点；end_date写20220110，这正是标题里指定的目标截止日，注意格式是YYYYMMDD；adjust传空字符串表示不复权，传qfq是前复权，hfq是后复权。
返回的DataFrame字段通常包含：日期、股票代码（部分版本无）、开盘、收盘、最高、最低、成交量、成交额、振幅、涨跌幅、涨跌额、换手率。这里我强烈建议你先打印dtypes，重点看成交量是什么类型、日期是什么类型。成交量在多数接口里返回的是“手”为单位，数值通常是整数，但如果你拿到的是带小数或者特别大的数，就要怀疑单位是不是“股”。这个差异会在合并全部股票数据时造成严重的数量级错误。
在跑全量之前，我建议做一个快速核对：拿这只股票某一天的收盘价和成交量，跟行情软件对照。误差在零点几个点以内是正常的，差出几个数量级就说明单位或者字段映射错了，赶紧回头改。
3.3 第三步：多线程批量下载与断点续拉
单只股票的函数通了，批量就好办了。全市场五千只股票逐只循环，最直接的方式是for循环加time.sleep，但太慢。我推荐用ThreadPoolExecutor控制并发数，限制在8到16个线程之间，加上失败重试和本地断点机制。这里有一个工程要点：先让脚本支持断点续拉，再考虑速度。因为全量下载过程中网络抖动几乎一定会打断几次，没有断点机制就只能从头再来。
import akshare as ak import pandas as pd from concurrent.futures import ThreadPoolExecutor, as_completed import os import time import random stock_list = pd.read_csv("./data/stock_list.csv") symbols = stock_list["code"].tolist() OUTPUT_DIR = "./data/raw" os.makedirs(OUTPUT_DIR, exist_ok=True) MAX_WORKERS = 12 RETRY_TIMES = 3 def fetch_daily(symbol: str): file_path = os.path.join(OUTPUT_DIR, f"{symbol}.parquet") # 已下载且非空则跳过，实现断点续拉 if os.path.exists(file_path) and os.path.getsize(file_path) > 0: return symbol, "skip" for attempt in range(RETRY_TIMES): try: df = ak.stock_zh_a_hist( symbol=symbol, period="daily", start_date="19900101", end_date="20220110", adjust="" ) if df is not None and len(df) > 0: df["symbol"] = symbol df.to_parquet(file_path, index=False) return symbol, "ok" else: # 空数据说明可能未上市或该代码无交易 pd.DataFrame().to_parquet(file_path, index=False) return symbol, "empty" except Exception as e: if attempt < RETRY_TIMES - 1: time.sleep(random.uniform(1, 3)) else: return symbol, f"fail:{e}" results = [] with ThreadPoolExecutor(max_workers=MAX_WORKERS) as executor: future_map = {executor.submit(fetch_daily, s): s for s in symbols} for future in as_completed(future_map): symbol, status = future.result() results.append((symbol, status)) status_df = pd.DataFrame(results, columns=["symbol", "status"]) status_df.to_csv("./data/download_status.csv", index=False) print(status_df["status"].value_counts())这段代码有三个设计点需要说明。第一，文件已存在且大小不为0就跳过，这就是断点续拉的核心，跑了一半中断后重新执行脚本，会直接跳过已完成的部分。第二，重试机制加了随机休眠，避免集中重试触发源站限流。第三，每个文件先按股票代码单独存parquet，不急着合并成一个大文件，这样单只股票损坏只影响自己，不用全部重拉。
关于并发数，代码里写的MAX_WORKERS=12，这个值不是越高越好。开源接口背后是网页服务，并发过高容易触发封禁或者大量超时。我一般建议先设4跑一小批，观察成功率和返回速度，再决定是否上调。如果大量请求超时，说明并发太高，赶紧降下来。
下载完成的判断标准不是“所有接口都返回了”，而是download_status.csv里没有fail记录。如果有fail，把这些代码重新喂给脚本跑一轮即可，这也是状态文件存在的意义。
4. 清洗与对齐：复权、停牌和交易日历的联动处理
4.1 复权三选一：不复权、前复权、后复权各归其位
下载完了不代表能直接用。日线数据的复权处理是第一个绕不开的问题。简单来说，一只股票在除权除息日，交易所会把价格往下调整，同时股本变大。不复权数据里，除权日会出现一根明显向下跳空的K线，但这一天投资者并没有亏钱，价格下调只是因为每股含权变化了。如果不做任何处理直接用这根K线计算收益率，你会得到一个巨大的“假亏损”或“假收益”，策略回测全被污染。
前复权是把当前价格当作基准，把历史价格按复权因子往下调整。它的优点是图看起来连续，直观。缺点是，只要未来发生新的除权事件，所有历史价格都会被重新计算一遍。前复权数据今天和历史快照日的计算结果不同，对回测研究来说是不可复现的。
后复权是把上市首日当作基准，用累计因子让价格趋势保持真实。它的历史价格不会因为未来事件变化，适合做收益计算。代价是后复权价格数值比较大，看起来不直观，而且日线上显示的价格和投资者实际看到的成交价不一样。
我建议存储用后复权或不复权，展示用前复权。具体到本标题，目标截止到2022年1月10日，如果你要保证“历史至今”这个口径稳定，就得选不复权或后复权。方案是原始数据下载时存不复权，同时保留一份后复权字段，这样两种用途都有。过程中的实现要牢记：复权是对价格做的处理，成交量一般不按复权因子缩放，除权日的成交量只反映当日实际成交，这个常识很多人用错。
4.2 停牌缺失怎么补：补Null还是补0
股票停牌时接口不返回数据，导致日线上出现“空洞”。问题在于：策略代码在计算收益率、移动平均或因子信号时，经常要求日线在时间轴上是连续等间距的序列，否则会出现“把昨天前天的数据当今天”的错位。所以怎么补停牌日，取决于你后续的用途。
用于K线绘图和人工复盘时，缺口不需要补。用于因子计算和机器学习时，必须把缺失日补回来。补的规则不是简单填0，而是先按交易日历把缺失日期枚举出来，用None或NaN标记价格，成交量补0。注意，涨跌幅不能直接填0，因为停牌日和正常交易日的涨跌幅定义不同，填0会让模型误以为停牌时收益率为0，这其实是对因子数据的误导。
常见的补全代码逻辑如下：
import pandas as pd # 假设df是某只股票清洗后的日线，包含date列和价格列 # 思路是把它左连接到交易日历上 df["date"] = pd.to_datetime(df["date"]) df = df.set_index("date") # 用交易日历重建完整索引 # trade_cal 为完整交易日历，来自第3章或外部对齐 df = df.reindex(trade_cal) # 先备份涨跌幅和成交量再填充 df["volume"] = df["volume"].fillna(0) df["amount"] = df["amount"].fillna(0) # 价格和收益率不填0，保持NaN，让下游代码自行识别这段代码核心是reindex，它会自动根据交易日历补出缺失日期，本来没有数据的位置变成NaN。成交量补0，因为停牌期间的“成交”是0；成交量之外，复权因子、涨跌幅、换手率这类字段保持NaN，不建议填充成0。补完之后建议看一眼停牌日数量占全样本的比例，长期停牌的股票要单独确认是否纳入后续分析，否则一个连续停牌半年的样本可能会对因子回测产生你意想不到的杠杆作用。
4.3 上市首日与代码变更：别被历史留白骗了
全市场下载后，你会发现一部分股票的parquet文件行数特别少，只有几百行甚至几十行。这不是数据丢失，是它本身上市时间晚。上市首日是这只股票数据段的起点，首日之前没有交易记录，保持NaN比把数据往前挪要稳重得多。但在做统一对齐时，有一种情况要小心：股票代码可能会变更，比如吸收合并后更换代码或重新上市，旧代码的历史数据属于另一家公司。如果直接按代码合并日线，等于把两只不同公司的时间序列首尾拼接在一起，回测时会产生一个毫无意义的“穿越”样本。
所以代码变更处理的一个比较稳妥的做法是：入库时多保留一个字段，比如名称或所属股票池ID作为辅助校验。实践中，全A股六千多行数据里，真正出现代码切换的案例屈指可数，但足以让一个单标的策略结论完全改变。遇到这种情况，我的处理方式是先不急于拼接，把代码切换点的前后日线分开保存，后续分析时显式指定“从新代码上市日开始”。
另一个容易被忽视的是新股上市首日的数据特征。新股首日往往没有涨跌幅限制，或者有明显异常波动，换手率极高，成交量相对后续交易日整体放大一个量级。这些极端点会让后续的因子或统计检验失真，很多团队的习惯是直接剔除上市首日后开始计算信号。是否需要剔除取决于你的策略，但不要默认包含它。
5. 沪深日线项目避坑清单：五个现象与排查手记
5.1 现象一：数据停在几天前，增量更新少了一天
增量更新是例行维护的一部分，但运行一段时间后容易发现数据只更新到某一天，之后的新交易日没有进来，重跑依然如此。原因是多方面的：一是你在当天收盘前跑了增量，行情还没走完，拿到的是半个交易日的数据；二是接口或上游数据源缓存了旧响应，短时间内重复请求拿不到新数据。
解决思路：增量脚本固定到收盘后一个半小时再跑，让源站有时间结算当日数据；同时把“截至日期当天”的请求加上延迟，不要在一个小时窗口内重复拉同一只股票。更稳妥的是，增量时不只拉新增天数，而是回退三个交易日重拉，用新数据覆盖旧数据，防止单日缺一条或数据错乱。这个回退窗口设置成3个交易日足够覆盖大多数情况。
5.2 现象二：除权日跳空被误判成策略收益
回测某只股票时发现，某一天收益率突然异常放大，叠加交易信号后看起来像是策略的“天才捕捉”。实际去核对K线，发现这一天是除权除息日，价格跳空是复权处理不当造成的，策略其实没有在那个位置赚到钱。这通常是因为你用了前复权数据但除权日期对不上，或者在计算收益率的代码里把前复权价格和不复权价格混着用。
排查方法：找到异常收益率的日期，去对照该股票的除权除息公告或股本变动记录，如果该日附近有分红送转，基本可以锁定是复权问题。解决办法是回测一律用后复权或不复权作为收益计算基准，前复权只用于展示。记住这个代码习惯：计算收益率的时候，永远不要在逻辑里同时出现“前复权价格”和“成交量”然后假设它们来自同一个日线语义。
5.3 现象三：成交量在“股”和“手”之间反复横跳
全市场合并后统计总成交量，发现某些股票的量级明显不对，有的数据点比其他股票大100倍，或者同一只股票在不同时期绝对值量级悬殊。本质是数据源在“股”和“手”两个单位上切换了，有些接口在填单时明确标注成交量单位，而有些会用默认单位返回。叠加成csv时如果不做统一换算，直接合并会造成统计口径混乱。
解决办法在阶段入口就固化单位约定：统一按“股”存储，读取时乘以100转成“手”。落盘前用一条断言校验：当日成交量除以该股流通股本，得到换手率，如果换手率小于0或大于某个合理上限（比如0.3），就要检查这一行的单位。这条校验逻辑要写在统一清洗阶段，不要在每个下游分析里分别处理。
5.4 现象四：前复权价格“自己会变”，回测结果每次不一样
某个策略在月初回测得到一组收益数字，月末再跑一遍，结论变了，而策略代码一行没动。数据排查发现是前复权机制导致的：这期间某只成分股发生了新的除权，前复权因子把所有历史价格重算了，历史输入变了，所以回测输出变了。这不是程序bug，而是复权方式的固有属性。
想避免这种反复，就要接受“历史数据是一个动态对象”这一事实。项目里对这种情况有一个简单的工程约定：把下载时的复权因子文件存档，作为一个独立版本固化下来。这样不管未来除权事件怎么变化，回测时都沿用这套归档因子。简单来说，就是给数据仓库加上版本概念，跑回测时锁定一个版本，而不是永远用最新数据。否则过了半年，你都不清楚自己的回测结论是基于哪个快照得出的结论。
5.5 现象五：停牌日被填成0，因子分析被污染
补全缺失交易日时，为了避免下游代码因为缺失报错，很多初学工程里的做法是直接把所有缺失值填充成0，包括价格和涨跌幅。这样做表面“平稳”，实际上制造了一个假象：停牌日该股收盘价没有变化，收益率为0。因子模型会把这些0当成真实观测，低估股票的真实波动率，尤其在停牌密集的个股上，因子值会被明显拉低。
正确的处理是：成交量、成交额可以填0，因为停牌期间确实没有成交；价格和收益率保持NaN。如果你的因子库代码不能容忍NaN，就在调用因子计算前显式按交易日历dropna或者用前向填充填充价格，但不要用0。前向填充的语义是“沿用最近有效价格”，比0更接近真实市场状态。这是我在一个长期停牌股票的因子分析里踩过的坑，印象很深，处理原则就四个字：分而治之，该填的填，不该填的不动。
6. 进阶：把本地日线库封装成回测能直接调的接口
数据仓库建好之后，最后一个要落地的点是封装。不要让你的策略代码直接读parquet文件，再自己拼字段拼单位，那会让错误四处流窜，每次排查都是一场灾难。我习惯的做法是做一个薄薄的读取层，封装成一个简单的函数，对外统一返回“日期、开、高、低、收，成交量、成交额、涨跌幅、复权因子”这几列，对内统一处理单位、停牌标记和复权切换。这个读取层是所有策略脚本的公共依赖，也方便日后切换存储介质。
import pandas as pd def get_daily(code: str, start: str, end: str, fq: str = "none"): """ 从本地日线库读取单只股票日线。 fq: none 不复权 / hfq 后复权 / qfq 前复权 """ file_path = f"./data/daily/{code}.parquet" df = pd.read_parquet(file_path) df = df[(df["date"] >= start) & (df["date"] <= end)].copy() if fq in ("qfq", "hfq"): df["open"] = df["open"] * df["adjust_factor"] df["high"] = df["high"] * df["adjust_factor"] df["low"] = df["low"] * df["adjust_factor"] df["close"] = df["close"] * df["adjust_factor"] return df.sort_values("date").reset_index(drop=True)这个封装有两个细节值得谈。第一，不会在读取层里篡改成交量和换手率，单位统一在写入层已经处理过，读取层只保证“拿到的就是这个口径”，不做二次换算。第二，前复权转换依赖的adjust_factor，需要从复盘因子表中读取，而这张表在版本归档时已经固定。也就是说，这里的qfq是“按历史归档因子的前复权”，而不是“实时计算的最新前复权”，这样可以避免前面的复权漂移问题。
封装好之后，还要做一次全市场的终验。我的习惯是随机抽5到10只股票，把最后一年的数据和行情软件人工对照，具体核对项目是：某日的开盘、最高、最低、收盘四个价格是否一致，成交量是否在千分之三误差以内，除权日附近的跳空是否和复权方式匹配。再抽查三只长期停牌股票，确认停牌日期在原始数据里是缺失，补全后是NaN加成交量0。这套终验流程跑一次大约半小时，但它能筛出绝大多数数据落地过程中的静默错误。
最后说一个我这几年做数据工程养成的小教训：数据脚本永远不要只写“能用”，还要留下“可重跑”的能力。每次下载任务开始前，我习惯先打印目标股票数、起始日期、终止日期、复权方式这四个字段，确认无误再回车。这个习惯看起来有点固执，但确实帮我少重跑了很多次全量任务。数据工程就是个慢功夫，你磨得越细，后续做策略时越省心。希望这些经验和坑能帮到你，至少在你第一次跑全市场日线下载时，知道该在哪里停下来校验一下。
本文还有配套的精品资源，点击获取
