baostock：安静可靠的"备用发电机"
我的掌握程度：
先掌握这个答案
定位：免费的A股历史K线+财务数据库——注册即用（login机制）、接口签名稳定（多年不大改）、数据更新延迟（T+1或更晚——不适合实时、适合历史）。数据特点：复权三档参数（前/后/不复权）清晰、财务字段规整——但公告日字段弱于tushare（防前视仍以tushare为主）。多源体系角色：①对账第三方：akshare与tushare打架时，baostock当裁判（三方两票制）；②灾备：主源接口集体失效时（源网站改版潮）顶上——历史K线这类慢变量它的稳定性优势最大。使用模板：bs.login()→bs.query_history_k_data_plus(...)→bs.logout()（记得登出）。
先读结论，再核对下方使用边界；数字例题为教学情景，涉及实际行情与规则时请核对原始来源。
从理解到使用
本阶段实战方法 · 一条能复现的数据流水线
把接口返回的数据变成可用于因子研究的面板时，先处理时点、主键与单位。
- 建立数据字典：字段、单位、时区、交易日历、数据源、抓取时间、原始价与复权因子。
- 用(date, code)查重，区分停牌、未上市、窗口不足和真实缺失；不要用向后填充把未来值带回过去。
- 保存原始快照与清洗日志，固定随机种子和环境版本；接口字段变化时先核对官方文档。
使用边界
- 报告期不等于公告可用日，盘后公告通常不能用于当天收盘前决策。
- API输出名为“动态市盈率”时不能直接改名TTM；浏览器练习不支持任意原生库或行情抓取接口。
背景 · 从一个困惑说起
数据源组合里需要一个「安静的角色」：akshare活跃但接口常变、tushare要积分——baostock免费注册、接口稳定、更新稍慢——像一台备用发电机：平时不用，停电时救命。
由此产生的问题
baostock的定位与数据特点（复权口径/更新频率）？在多源体系里扮演什么角色（对账第三方/灾备）？它的登录机制与使用模板？
核心概念
定位：免费的A股历史K线+财务数据库——注册即用（login机制）、接口签名稳定（多年不大改）、数据更新延迟（T+1或更晚——不适合实时、适合历史）。数据特点：复权三档参数（前/后/不复权）清晰、财务字段规整——但公告日字段弱于tushare（防前视仍以tushare为主）。多源体系角色：①对账第三方：akshare与tushare打架时，baostock当裁判（三方两票制）；②灾备：主源接口集体失效时（源网站改版潮）顶上——历史K线这类慢变量它的稳定性优势最大。使用模板：bs.login()→bs.query_history_k_data_plus(...)→bs.logout()（记得登出）。
为什么需要它
①对冲「单点故障」：研究流水线依赖单一数据源=把项目命运押在别人的网站改版上——第三方备份是最便宜的保险；②两票制对账的统计学：两个源可能同错（同源抓取），三个独立源两两对照才接近真相——数据可信度的冗余设计；③「更新慢」的重新理解：历史研究的原料不需要实时——慢而稳的数据在回测场景里反而是优点。
实际应用场景
建议架构：日常=akshare（快）+tushare（关键）；每周对账=baostock抽样；灾备预案=一键切换脚本（主源失败自动降级到baostock的历史档）。
与之前知识的联系
q-321/322（主源组合）的备份件；q-327（机构终端）之前的免费生态收官；数据可信度问题呼应q-071（体检）的多源交叉。
⚠ 常见误解
- 更新慢=没用：历史研究用不到今天的行情——它的稳定性恰是回测可复现的好朋友
- 三个源数据打架听多数：若两源同源（抓同一页面），「多数」是假象——查各源的底层来源再投票
- baostock登录失败很常见：账号密码用注册邮箱；login失败先查网络代理（它对代理敏感）
🛠 本题实践任务
注册baostock跑通一次日线查询（注意adjustflag三种口径各拉一天对比）；把它加入你的对账脚本：下次双源差异>0.1%时自动触发第三方。
💡 提示（先自己想5分钟再看）
sh.600519/sz.000001的代码格式带交易所前缀；对账自动化是数据工程的进阶动作。
✅ 验收标准
三档复权对照+对账脚本升级。你的数据体系完成「三足鼎立」。
在你的浏览器内运行。首次需联网下载 Python；支持标准库和 Pyodide 提供的 NumPy、pandas 等包。行情抓取、系统文件访问和部分第三方库请在本地环境运行。输出自检仅比对结果关键词，不代替逻辑审查。
Python · 独立工作线程 · 执行限时10秒
🤖 AI导师
导师会先检查你的前置知识（多源策略），再用案例、公式和代码帮助理解。此功能需要先启用服务。