它不用 akshare，也不用 tushare
requirements.txt 的 19 项里没有 akshare、没有 tushare，东财一侧走的是 eastmoneypy，聚宽一侧走的是 jqdatapy。所以「ZVT 基于 akshare 取数」的说法是错的；这属于两套彼此独立的取数实现。
ZVT 项目研究站 · 数据源与前置条件
ZVT 数据源清单：八组 provider，各自要不要账号先说清楚
官方 README 对数据源只有一句话：「数据可以从不同 provider 更新，这让系统稳定」——既没给清单，也没说哪些要账号。本页把 src/zvt/recorders/ 下的八组目录逐个打开，列出实际文件数与覆盖范围，并标明前置条件。
八组 provider 目录（括号内为 Python 文件数）
em26
eastmoney23
joinquant21
exchange11
sina9
qmt7
jqka4
wb4
Provider list
八组 provider：覆盖什么、要不要账号
下表按目录整理，前置条件一列是判断「我能不能用」的关键——官方 README 没有这一列。
| provider 目录 | 文件数 | 典型覆盖 | 前置条件 | 适用场景与注意点 |
|---|---|---|---|---|
em | 26 | 标的清单（A 股/港股/美股/指数/ETF/板块）、K 线、龙虎榜、股东、财报、新闻、国债收益率 | 无账号；requirements.txt 里带 eastmoneypy | A 股主力数据源，覆盖最广；接口来自公开站点，站点改版会影响可用性 |
eastmoney | 23 | 财务报表三张表、财务指标、分红融资、股东与高管交易、板块清单 | 无账号 | 与 em 同属东财体系但目录不同，功能互有重叠；财务数据主力 |
joinquant | 21 | 标的清单、K 线、估值、融资融券、资金流、ETF 估值、交易日历、基金清单 | 需要聚宽账号（jq_username / jq_password） | 数据规整度高，但依赖账号与配额；没有账号时这条线完全不可用 |
exchange | 11 | 交易所侧的标的清单、指数清单、指数成分股、股票汇总 | 无账号 | 权威性最高的一路（交易所官网口径），但覆盖窄、字段少 |
sina | 9 | 板块清单与板块资金流、个股资金流、ETF 与指数 K 线 | 无账号 | 板块口径与东财不同，做长期对照时要固定一家 |
qmt | 7 | 实时行情（stock_quote / stock_quote_log）、标的清单、K 线、指数 | 需要 QMT 数据授权，README 写明「请联系作者」 | 配置里登记了 provider 的实时来源只有 qmt 一个；本地配置里 qmt_mini_data_path 默认是 D:\qmt\userdata_mini |
jqka | 4 | 同花顺一侧的补充数据 | 无账号（按目录推断） | 文件少，覆盖面有限，属于补充来源 |
wb | 4 | 世界银行口径的国别与经济数据 | 无账号 | 宏观研究可用，与股票业务基本无关 |
怎么读这张表：「无账号」只表示不需要登录凭据，不代表数据可以随意商用或无限抓取。各数据源的条款、频率限制与合规要求由数据源方决定，使用前自行确认（本站不代答，见证据台账 G-04）。
How selection works
同一个 schema 有多个 provider 时，框架怎么选
这是 ZVT 数据层最容易被忽略的一条规则，也是「为什么我的数据和别人不一样」的答案。
每个 schema 维护一张 provider → recorder 的映射表
README 展示了
Stock.provider_map_recorder的输出：joinquant、exchange、em、eastmoney 四个键各自对应一个 recorder 类；Block.provider_map_recorder则是 eastmoney 与 sina 两个。要看某个 schema 支持哪些源，直接打印这张表最快。不传
provider时用第一个官方说明「你可以用任何 provider 取数据，默认用第一个」。所以不写 provider 的代码在不同版本、不同机器上可能取到不同来源的数据——做可复现研究时建议显式写 provider。
不同 provider 的口径并不一致
板块成分股是最明显的例子：东财与新浪的行业/概念分类不同，同一个板块名可能对应不同成分。财务数据、资金流口径在不同来源之间也可能有差异。
写入时可以混源，但查询时要拆开
同一张表里可能同时存在来自多个 provider 的记录。
query_data支持按 provider 过滤，做一致性检查或换源对比时要用它，不要直接对混在一起的数据取平均。
>>> Stock.provider_map_recorder
{'joinquant': zvt.recorders.joinquant.meta.jq_stock_meta_recorder.JqChinaStockRecorder,
'exchange': zvt.recorders.exchange.exchange_stock_meta_recorder.ExchangeStockMetaRecorder,
'em': zvt.recorders.em.meta.em_stock_meta_recorder.EMStockRecorder,
'eastmoney': zvt.recorders.eastmoney.meta.eastmoney_stock_list_recorder.EastmoneyChinaStockListRecorder}Scope
几点关于数据源的事实校正
这四条在二手教程里经常被说反，逐条给出仓库里的依据。
文件数不等于可用数据量
一个 recorder 文件通常对应一张表或一个接口，但能否取到取决于站点是否改版、是否需要凭据。26 个文件的 em 也不是每个接口都还能用——以实际调用结果为准。
实时行情只有一条路
config.json 的 storage.schema_providers 里，stock_quote 与 stock_quote_log 只登记了 qmt 一个 provider。也就是说，没有 QMT 授权就没有实时行情，这不是配置问题。
provider 是可以自己加的
ZVT 官方提供了数据扩展教程（zvtvz.github.io/zvt/#/data_extending），并留有 src/zvt/autocode/ 目录（含代码模板），说明扩展 provider 是一条被支持的路径，但需要按 ZVT 的约定实现 recorder。
证据边界：上表中「无账号」是按 recorder 目录与官方文档推断的，本站没有逐一调用验证；各源实际可用性与条款以官方与数据源方为准。
Decision
按你的条件选数据源：四种情形
同一份数据可能有多个来源，怎么选取决于你有没有账号、要不要实时、能不能接受口径差异。
| 你的条件 | 建议数据源 | 理由 | 注意点 |
|---|---|---|---|
| 没有任何数据账号，只想先跑通 | em 或 eastmoney | ZVT 这两个 provider 都不需要登录凭据，且覆盖 A 股主力数据 | 公开站点接口可能变动，长期项目要做失效预案 |
| 已有聚宽账号 | joinquant | 数据规整、覆盖估值与资金流 | 注意账号配额；不要把账号密码写进代码仓库 |
| 需要实时行情 | qmt | 实时表在配置里只登记了这一个 provider | 需要 QMT 授权与本地数据目录配置，门槛最高 |
| 研究板块轮动 | eastmoney 与 sina 二选一并固定 | 两家都有板块与资金流 | 分类口径不同，中途换源会让历史序列断裂 |
| 要交易所原始口径 | exchange | 数据来自交易所，权威性最高 | 覆盖窄、字段少，通常只用于核对清单与成分股 |
Reliability
数据源会失效：四种典型故障与应对顺序
ZVT 的 provider 多数依赖公开站点，这是它数据层最现实的风险。下表把故障现象、判断方式与应对写清楚。
| 故障现象 | 常见原因 | 怎么判断 | 应对顺序 | 注意点 |
|---|---|---|---|---|
| 取数请求超时或直接被拒 | 本地代理默认值不可用，或网络出口受限 | 换一个不依赖代理的方式验证连通性 | 先查 config.json 的代理项，再查网络 | 这是新装环境最高频的一条 |
| 返回字段为空或表结构变了 | 数据源站点改版，recorder 解析失败 | 对比日志里的解析异常与历史记录 | 先看仓库 issue 是否已有人报告；再用同 schema 的其它 provider 顶住 | 这类问题不在框架可控范围，等上游修复或自行改 recorder |
| 只能取到最近的数据 | 免费接口的历史深度有限，或账号权限不足 | 对同一标的取不同年份的区间做对比 | 换有更深历史的 provider，或降低时间跨度要求 | 不同源的历史深度差异很大，不要拿示例的深度当承诺 |
| 限流/频率告警 | 批量写库太快 | 看日志中的限流提示与失败重试记录 | 增大 sleeping_time，把全市场拆成小批次 | 降速后总耗时会显著增加，要提前安排任务窗口 |
| 同一只标的两个源数值不一致 | 复权口径、数据口径或更新时间不同 | 用 query_data 的 provider 参数拆开对比 | 固定一个源作为研究基准，并记录在项目里 | 不要把两个源的数值混着做因子计算 |
多 provider 的真正价值：官方说「同一个 schema 可以挂多个 provider，这是系统稳定性的基石」。上面五行的应对方式都建立在这一条上——某个源失效时，研究不必停。但请记住：换源会换口径，连续性要求高的因子研究要在项目里锁死一个源。
FAQ
数据源常见问题
回答以仓库目录、requirements.txt 与 README 为准。
必须注册聚宽才能用 ZVT 吗？
不是。聚宽只是 8 组 provider 之一，而且是最需要前置条件的一组。只做 A 股行情与财务的话，东财一侧（em / eastmoney）不需要账号就能用；但要是你的目标表只有聚宽侧实现，那就绕不过账号。
新浪板块和东财板块有什么区别？
主要差别在分类口径：同样叫「概念」的两个源，成分股集合可能不同（例如题材归类标准不一样）。README 里两者都被注册为 Block 的 provider，说明框架层面都支持，但一致性要你自己保证——做时序研究前先固定一家。
没有 QMT 就一定拿不到实时数据吗？
从配置看是这样：stock_quote 与 stock_quote_log 的 provider 列表里只有 qmt，而 README 明确说实时行情基于 QMT、需要联系作者开通。想要实时数据的替代做法是另接自己的行情源，但那已经不在 ZVT 的 provider 体系内。
数据可以商用吗？
代码是 MIT，但数据不是。每个 provider 背后的数据源有各自的条款与限制，例如公开站点的抓取频率、账号制数据源的使用范围。ZVT 只提供取数工具，不改变数据的授权归属。本站不提供法律意见，请按数据源方条款自行判断。
某个 provider 突然失效了怎么办？
这是依赖公开站点的必然结果。处理顺序：①看仓库 issue 里是否已有人报告；②换同一 schema 下的其它 provider 先把研究推进下去（这正是多 provider 设计的意义）；③如果长期失效且没有替代源，才考虑自己按 autocode 模板写一个 recorder。
和 EasyClaw 的取数技能比，差在哪？
形态不同。本机技能 akshare-finance、tushare-finance、mx-data 是「问一次取一次」，装上客户端就能用；ZVT 要把数据写进本地库再查询，换来的是可复现与可复用。技能侧不建本地库、也不跑因子流水线；两者无已证实集成。