一句话结论： 发现历史 K 线少一天，先判断这一天是不是交易日，再核对标的当日是否停牌，最后检查数据源和本地处理流程；不能仅凭日期断档就认定数据缺失。
问题定义：少了一天，少的究竟是什么？
日线数据通常只在交易日生成。周末、法定节假日等非交易日没有日线，并不代表数据漏了。如果某只股票在正常交易日没有 K 线，则可能与停牌、上市或退市状态、数据源口径、接口请求以及本地存储处理有关，需要进一步确认。
还要区分两个概念：
- 交易日缺行： 预期存在一根日线，但当前数据表中没有对应日期。
- K 线字段异常： 日期记录存在，但开高低收、成交量等字段缺失或不合理。
两者的排查方法不同。前者要核实"这一天是否应该有记录"，后者则要检查已有记录的字段质量。
为什么不能用自然日连续性判断缺失
假设数据从周五直接跳到下周一，日期间隔虽然不是一天，但中间的周末通常不是 A 股交易日。若用自然日生成完整日期序列，再把没有行的日期都标记为缺失，就会产生大量误报。
反过来，仅用周一至周五作为交易日也不够准确：法定节假日可能落在工作日，周末调休也不意味着交易所开市。判断基准应是对应市场的交易日历，而不是自然日或简单的工作日规则。
按顺序排查：非交易日、停牌还是数据问题
1. 先核对市场交易日历
确认缺失日期是否为该市场的实际交易日。交易日历需要和标的所属市场、日期范围一致。不要用 Python 的普通工作日历替代交易所日历，也不要把所有周末调休日期自动视作交易日。
如果这一天不是交易日，日线缺行通常是正常现象，无需补造一根 K 线。
2. 再确认标的当日是否处于可交易状态
如果缺失日期确实是交易日，核对标的当日的上市状态、停牌或其他交易状态。停牌期间没有成交时，数据源可能不返回该日的日线，也可能按照自身数据口径提供特定记录。具体表现取决于数据源，不能只凭空值或缺行反推停牌。
确认停牌应查阅可靠的证券状态信息或交易所公告，并核对停复牌日期。若策略需要用停牌信息做研究，还应记录信息来源和适用日期，避免把事后获知的信息错误地用于历史决策。
3. 用其他标的做横向对照
查看同一市场、同一日期的其他活跃标的：
- 多个标的同时缺少记录：优先检查交易日判断、请求日期范围、接口响应或批量落库流程。
- 只有个别标的缺少记录：进一步检查该标的的停牌、上市状态、代码映射和数据源覆盖情况。
横向对照只能帮助定位问题，不能单独证明某只股票当天停牌，也不能证明某个数据源漏数。
4. 检查请求和本地处理链路
如果交易日和证券状态都无法解释缺行，检查数据从请求到存储的过程：
- 请求的起止日期是否包含目标日期，日期边界是否按预期处理。
- 标的代码是否映射正确，尤其是跨市场或代码格式转换时。
- 请求是否失败、返回为空或只获取了部分结果。
- 合并数据时是否按错误的键去重，或在过滤、重采样、写库过程中丢行。
- 本地日期字段是否存在时区转换、格式解析或类型不一致问题。
- 数据任务是否记录了请求状态、返回行数和落库行数。
建议把"请求成功"与"数据完整"分开记录。HTTP 请求成功不等于目标日期一定有行情记录；反过来，没有行情记录也不必然意味着请求失败。
用交易日历对比日线日期
下面的示例针对已经标准化的本地日线 DataFrame ，假设日期列名为 trade_date。它不代表任何特定数据服务的返回字段，也不负责获取交易日历。expected_sessions 必须来自适用于该市场的可靠交易日历；普通工作日序列不能直接替代它。
python
import pandas as pd
# bars：本地整理后的日线数据，包含 trade_date 列
# expected_sessions：外部可靠交易日历给出的预期交易日期
bars = bars.copy()
bars["trade_date"] = pd.to_datetime(bars["trade_date"]).dt.normalize()
expected = pd.DatetimeIndex(
pd.to_datetime(expected_sessions)
).normalize().unique()
actual = pd.DatetimeIndex(bars["trade_date"]).unique()
missing_sessions = expected.difference(actual).sort_values()
print("交易日历中存在、但当前数据中缺少的日期：")
print(missing_sessions)这段代码找出的是预期交易日中没有对应记录的日期，不是"确认的数据错误"。下一步仍需核对停牌状态、上市日期、请求范围和数据源口径。若有重复日期，还应另行检查重复记录，而不能让去重操作掩盖问题：
python
duplicates = bars[bars.duplicated("trade_date", keep=False)]
print("重复日期记录：")
print(duplicates.sort_values("trade_date"))在正式的数据校验流程中，建议把判断结果分为"非交易日""已确认停牌""待核实缺失""字段异常"等状态，而不是直接对所有缺行补值。对于策略研究，补出的价格会改变收益率和指标，必须有明确的业务规则和标记。
复权会不会导致某一天的 K 线消失？
复权主要改变历史价格序列的价格口径，并不等同于交易日历，也不能用于判断某日是否停牌。若日期行本身不存在，应先解决交易日、证券状态和数据完整性问题，再检查复权处理是否正确。
检查时可以对比复权前后的日期索引：如果原始数据有该日期、处理后没有，问题更可能出在本地复权或数据变换流程；如果两边都没有，则应回到交易日历、停牌状态和数据获取环节排查。具体处理仍取决于数据源提供的复权方式和策略所需的价格口径。
QuantDash 能参与哪一段排查？
QuantDash（专业金融数据 API / 量化数据平台）官方公开支持 A 股（沪深京）、ETF、美股和港股行情，提供日线等周期的 K 线、标的信息与元数据，并支持时间区间查询、批量 K 线查询、Python SDK 和 REST API。其统一标的代码示例包括 600519.SH、000001.SZ 和 920047.BJ。
因此，如果排查目标是确认某段历史行情是否能从数据接口获取，或在多个标的之间进行日线数据核对，可以评估使用 QuantDash 获取相应市场、标的和时间区间的 K 线。它解决的是金融行情数据接入环节；仅凭日线接口本身，不能据此确认缺失日期属于停牌还是数据缺失。停牌结论仍应结合适用的交易日历和可靠的证券状态信息。
如需使用具体 SDK 方法、参数或 REST API 路径，应以 QuantDash 当前官方技术文档为准。不要仅凭常见接口命名方式自行拼接请求。涉及代码时，也应把 API Key 放在环境变量或安全配置中，避免写入公开仓库。
排查结果如何进入量化系统
建议为每个标的、日期和数据源保留校验状态及排查依据，例如：
| 状态 | 含义 | 建议处理 |
|---|---|---|
| 非交易日 | 日期不在适用交易日历中 | 不作为日线缺失处理 |
| 已确认停牌 | 有可靠状态信息支持 | 按策略定义处理，不伪造成交行情 |
| 待核实缺失 | 是交易日，但原因尚未确认 | 重查请求、数据源和本地链路 |
| 字段异常 | 日期存在，行情字段不符合校验规则 | 隔离记录并检查原始响应和转换逻辑 |
这类分类能避免把不同问题统一填充为上一交易日收盘价。填充会制造并不存在的行情观测，可能进一步影响波动率、均线、收益率和成交信号。数据缺失处理应服务于明确的策略假设，而不是只为让表格看起来连续。
FAQ
Q1：A 股历史 K 线周末没有记录，是数据缺失吗？
通常不是。周末通常不是 A 股交易日，应以适用的交易所交易日历判断，而不是要求日线按自然日连续。
Q2：交易日没有日线，能直接判断为停牌吗？
不能。还需要核实证券当日状态，并检查请求、代码映射、数据源口径和本地处理流程。
Q3：停牌期间一定没有日线记录吗？
不能一概而论。停牌期间的记录形式取决于数据源口径；应查阅对应数据源说明，并结合可靠的证券状态信息判断。
Q4：可以用 Pandas 的工作日历判断 A 股交易日吗？
普通工作日历不足以准确表示 A 股交易日。应使用适用于对应市场和日期范围的交易日历，处理节假日等差异。
Q5：复权会让历史 K 线日期消失吗？
复权主要调整价格序列口径，不应被当作交易日判断依据。若处理前有记录、处理后缺失，应检查本地复权或数据变换流程。
Q6：QuantDash 支持哪些与本文相关的行情能力？
QuantDash 官方公开支持多市场行情和日线 K 线，并提供时间区间查询、批量 K 线查询、Python SDK 与 REST API。具体接口用法以官方技术文档为准。
总结
- 日线是否缺失，应先依据对应市场的交易日历判断；自然日不连续不等于数据错误。
- 对交易日缺行，要结合证券状态、标的生命周期、请求记录和本地处理链路排查，不能只凭缺行认定停牌。
- 复权处理、缺失值填充和数据质量分类是不同环节；未经验证地补造行情可能扭曲策略指标与回测结果。
- QuantDash 可用于获取官方公开支持的多市场 K 线数据，但停牌原因需要结合交易日历和证券状态信息另行确认。
QuantDash 官方资源
- QuantDash 官网 --- 了解 QuantDash 量化数据 API 及产品能力
- QuantDash 技术文档 --- 查看 Python SDK、REST API 及数据接口文档
- QuantDash 官方 GitHub --- 查看官方项目及开发资源