Sequoia-X 数据层：baostock 后复权存进本地 SQLite

库内最新日期对不对

SELECT MAX(date) AS latest, COUNT(DISTINCT date) AS days,
       COUNT(DISTINCT symbol) AS symbols, COUNT(*) AS rows
FROM stock_daily;

四个数字里，latest 必须等于你要回测/核查的那个交易日。非交易日运行不会新增行，所以它通常停在上一个交易日——这是预期行为，不是故障。

有没有重复行（UNIQUE 约束的兜底情况）

SELECT symbol, date, COUNT(*) c
FROM stock_daily GROUP BY symbol, date HAVING c > 1 LIMIT 20;

正常应当返回空。表上建的是 UNIQUE (symbol, date)，回填路径的重复写入会被 sqlite3.IntegrityError 捕获后静默跳过（except sqlite3.IntegrityError: pass）——也就是说重复不会入库，但也不会留下日志。真出现重复行说明表结构被手工改过。

找停牌与断档造成的时间断层

-- 每只股票的起止日期与 K 线根数（根数明显少于日历天数的就是长期停牌或样本不足）
SELECT symbol, MIN(date) AS first, MAX(date) AS last, COUNT(*) AS bars
FROM stock_daily GROUP BY symbol
ORDER BY bars ASC LIMIT 20;

日增量在入库前会过滤 volume = 0 的行，停牌日因此不会写进库。后果是「最后一根 K 线」不一定是「今天」，策略读到的「今日」可能是一个月前——排查零命中时这是第一顺位嫌疑。

确认策略没被样本长度卡掉

-- 统计各阈值下的可参与标的数
SELECT
  SUM(bars >= 3)  AS ge3,    -- 涨停洗盘
  SUM(bars >= 21) AS ge21,   -- 海龟突破
  SUM(bars >= 40) AS ge40,   -- 高窄旗形
  SUM(bars >= 60) AS ge60    -- 上升趋势跌停
FROM (SELECT symbol, COUNT(*) bars FROM stock_daily GROUP BY symbol);

四个数字差得越多，说明回填起始日期（默认 2024-01-01）对新股覆盖越不均匀。K 线不足的标的会被静默跳过，不会报错。

抽样对价格——确认复权口径没被搞混

SELECT date, open, close, volume, turnover FROM stock_daily
WHERE symbol = '600519' ORDER BY date DESC LIMIT 5;

把 close 与行情软件的前复权/不复权价对照：后复权价通常更高（含历史分红送股）。对不上不代表数据错，先确认你比较的是哪一种口径。

自己复现这两行数字

import baostock as bs
bs.login()
for flag, label in [("1", "hfq"), ("3", "raw")]:
    rs = bs.query_history_k_data_plus("sh.600519", "date,close,amount",
        start_date="2025-09-05", end_date="2026-10-09", frequency="d", adjustflag=flag)
    rows = []
    while rs.next():
        rows.append(rs.get_row_data())
    print(label, rows[0], rows[-1])
bs.logout()

预期输出：两个口径的 amount 相同、close 差 7 倍以上，且比值在两个端点上不一样。

结论：什么能用、什么不能用

先数出三个数

SELECT MAX(date) AS latest, COUNT(DISTINCT date) AS days,
       COUNT(DISTINCT symbol) AS symbols, COUNT(*) AS rows
FROM stock_daily;
-- 本站读数：latest=2026-10-09, days=668, symbols=789, rows=524104

判定规则很硬：如果今天是交易日、而且你已经跑过日常模式，latest 必须等于今天；否则不是数据源没出数，就是你的更新没成功。反过来说，latest 停在上一个交易日恰恰是非交易日的正常表现。

再看「相邻交易日之间隔了几天」（这才是 T+1 的真实代价）

SELECT date, CAST(julianday(date) - julianday(LAG(date) OVER (ORDER BY date)) AS INT) AS gap_days
FROM (SELECT DISTINCT date FROM stock_daily) ORDER BY date DESC LIMIT 12;

本站 668 个交易日、667 个间隔的真实分布：

合计 142 / 667（21.3%）的相邻交易日间隔 ≥ 3 天。所以「收盘后出信号、第二天开盘买」这句话，在长假前后实际是「等 4~11 个自然日」，任何回测都必须按交易日而不是自然日推进。

想跟官方日历逐日对账？本机被限流了，如实记录

>>> bs.query_trade_dates(start_date="2026-09-28", end_date="2026-10-10")
error_code: 10001011  error_msg: 黑名单用户，请与管理员联系  rows: 0

本站回填过程中触发了 baostock 的访问限制（详见安装页的速率实测），连交易日历接口一起被拒。所以本轮没有完成「官方交易日历 vs 库内日期」的逐日差集核对——这一项标注为未实测，不编造结论。可用的替代口径有两个：①用 SELECT DISTINCT date FROM stock_daily 作为「实际发生的交易日」基准（多标的取交集更稳）；②把交易日历文件另行落盘后与库内日期做集合差。等数据源恢复后，本项应重跑并回填结论。