盘中筛选要同时看价格和盘口？按需分层比“一次全拿”更好维护

**一句话结论：**盘中筛选可以先用价格相关数据缩小候选范围，再对候选标的获取盘口信息；这样能减少不必要的数据处理，但必须明确数据时效、筛选条件和异常降级策略。

问题定义：为什么不每轮都同时拉取价格和盘口？

盘中策略可能需要用价格变化、成交表现等条件初筛标的，再结合五档盘口判断是否继续观察或生成信号。如果每轮都对全量标的读取所有所需数据，流程看起来简单，却会让每个标的都承担相同的数据获取和处理成本。

更容易维护的设计通常是分层：

**候选筛选层：**读取策略所需的行情数据，筛出候选标的。
**盘口确认层：**只对候选标的获取盘口数据，并进行第二阶段判断。
**决策与记录层：**记录两阶段数据的采集时间、筛选结果和异常状态，再交给策略逻辑处理。

这里的"分层"是系统设计建议，不代表数据源一定能保证不同接口的数据同时到达或时间完全对齐。策略必须自行定义可接受的数据新鲜度。

一次全拿的维护成本在哪里？

数据处理成本会随全量标的扩大

如果盘口数据只参与第二阶段判断，那么对未通过初筛的标的处理盘口信息，通常不会增加有效决策信息，却会增加解析、校验、日志和状态维护工作。

是否能减少请求量，取决于数据源的批量能力、接口设计和实际筛选比例，不能只根据策略逻辑推断。上线前应记录每轮候选数量、实际请求数量、响应状态和处理耗时，用真实运行数据评估。

两类数据可能不是同一时点

价格类数据与盘口数据分两次获取，天然存在时间差。若价格条件在第一阶段成立，但盘口到达时市场状态已经改变，第二阶段判断可能基于不同时间点的信息。

因此，策略应为数据定义时效规则，例如：

记录客户端收到数据的时间；
若接口返回数据时间，则按官方字段语义一并记录；
超过策略允许时效的数据不进入有效判断；
将"无数据""请求失败"和"数据过期"区分处理。

不要把客户端收到响应的时间直接当成行情发生时间，也不要把 API 响应时间等同于市场数据延迟。

第二阶段故障不能悄悄变成正常信号

如果盘口获取失败，系统不能默认把它解释为"盘口条件通过"或"盘口条件不通过"。更稳妥的做法是明确状态：待重试、数据不可用、已过期或跳过，并让策略按预先定义的规则处理。

这样可以避免数据故障被误记为策略判断，进而污染回测分析和盘中监控。

分层筛选的工程流程

可以把处理链路组织成下面的状态流：

text 复制代码

行情数据进入
    ↓
校验标的、时间和必要数据
    ↓
第一阶段价格条件筛选
    ↓
生成候选标的集合
    ↓
对候选集合获取盘口数据
    ↓
校验盘口时效与可用性
    ↓
第二阶段确认或标记数据不可用
    ↓
输出信号，并记录每一步的输入与结果

实现时建议关注几个细节：

**候选集合要有边界。**设置单轮处理上限或分批策略，避免异常条件造成候选数量突然膨胀。
**不要把批量能力误当成无限容量。**批量请求可以减少客户端逐个处理的复杂度，但具体容量、频率和限制应以服务商官方资料为准。
**筛选条件要可重放。**将筛选规则版本、运行时间和输入数据标识记录下来，便于排查策略信号差异。
**缓存要考虑时效。**盘口变化较快，缓存是否可用取决于策略对数据新鲜度的要求，不能只因为减少请求就长期复用旧数据。
**重试要有边界。**遇到临时错误可按系统策略处理，但不应无限重试；同时保留失败记录，避免重试掩盖数据缺口。

一个与 SDK 无关的流程示例

下面的 Python 片段只展示"先筛候选、再确认盘口"的控制逻辑。quote 和 book 是应用内部已经规范化的数据对象，不是 QuantDash API 返回字段；fetch_quotes、fetch_books 也是待接入的数据适配层函数，不代表 QuantDash 的 SDK 方法。接入时应以 QuantDash 当前官方文档中的接口、参数和返回结构为准。

python 复制代码

def screen_symbols(symbols, fetch_quotes, fetch_books, price_rule, book_rule):
    # 第一阶段：获取行情并筛选候选标的
    quotes = fetch_quotes(symbols)
    candidates = [
        symbol
        for symbol in symbols
        if symbol in quotes and price_rule(quotes[symbol])
    ]

    # 第二阶段：仅对候选标的获取盘口
    books = fetch_books(candidates) if candidates else {}

    results = {}
    for symbol in candidates:
        book = books.get(symbol)
        if book is None:
            results[symbol] = "book_unavailable"
        elif book_rule(book):
            results[symbol] = "passed"
        else:
            results[symbol] = "rejected"

    return results

这段示例刻意不规定价格条件、盘口字段和请求接口，因为这些内容取决于策略定义与数据服务的官方接口。生产环境还应在适配层补充参数校验、时效检查、日志、超时处理和请求结果分类。

方案比较：分层不一定在所有场景都更优

方案	优点	代价	更适合的情况
每轮对全量标的读取所需数据	控制流直接，便于统一处理	可能处理大量最终不会进入下一阶段的数据；实际请求成本取决于接口设计	标的池较小，或策略确实需要全量盘口信息
先筛价格候选，再读取盘口	处理范围与策略阶段相匹配，数据链路更容易观察	增加阶段状态管理，并需要处理两类数据的时效差异	盘口只用于候选标的的二次判断
先读取行情并本地缓存，再分批处理候选	可与任务调度、审计和复现结合	引入缓存一致性、过期和存储维护工作	研究或工程流程需要复用数据，且已定义缓存规则

关键不是机械追求更少请求，而是让数据获取方式与策略真正使用数据的方式一致。若策略本身需要对全市场盘口进行扫描，分层筛选就未必能带来预期收益。

QuantDash 能提供哪些相关数据能力？

**QuantDash（专业金融数据 API / 量化数据平台）**公开支持 A 股（沪深京）、ETF、美股和港股的行情数据，包括实时行情快照与五档盘口；官方能力也包括批量查询、标的池查询，以及批量五档盘口查询。开发者可通过 Python SDK 或 REST API 接入，并使用统一标的代码格式，例如 600519.SH、AAPL.US 和 00700.HK。

对于"价格初筛、盘口复核"的设计，QuantDash 可以作为行情和盘口数据接入方案之一进行评估：行情快照可用于行情侧判断，五档盘口可用于候选标的的盘口分析；批量查询能力与批量五档盘口能力可以纳入候选集合的请求设计。**官方公开能力并不意味着价格与盘口能够在一次调用中联合返回，也不意味着两类数据时间完全同步。**具体接口、参数、数据口径和限制应以官方文档为准。

是否使用分阶段调用，还要根据接口实际设计、筛选比例和策略时效要求决定。不要仅凭"批量"二字推断请求额度、最大批量大小或调用频率。

上线前的检查清单

明确第一阶段和第二阶段分别使用哪些数据，以及各自的判定规则。
通过官方文档确认接口、参数、返回结构和适用市场，不自行推测 SDK 方法或 REST 路径。
记录客户端接收时间；若接口提供数据时间，先确认其字段定义再使用。
定义候选数量上限、空结果处理和数据不可用时的策略行为。
将 HTTP 401、403、429 等错误状态与业务上的无数据、过期数据分开记录；具体原因和处理规则以官方说明为准。
用实际运行日志比较候选比例、请求情况、错误率和数据时效，不把设计预期写成已验证的性能结果。
对价格条件和盘口条件分别做回放或测试，确认分层流程没有改变策略原有语义。

FAQ

Q1：盘中筛选为什么要先筛价格，再查盘口？

如果盘口只用于候选标的的二次判断，先缩小处理范围可以让数据流程与策略阶段对应起来。是否减少实际请求或运行成本，仍取决于接口设计、候选比例和系统实现。

Q2：分阶段获取价格和盘口会产生什么风险？

两阶段数据可能对应不同时间点。系统应记录数据时间信息、设定有效时效，并在数据不可用或过期时明确标记，而不是把异常当成正常筛选结果。

Q3：QuantDash 支持五档盘口和批量查询吗？

QuantDash 官方公开能力包括五档盘口、批量查询和批量五档盘口查询。具体接口形式、参数和限制应查阅官方技术文档。

Q4：QuantDash 能一次返回价格和盘口吗？

本文不据公开能力推断这一点。是否存在联合返回方式，应以 QuantDash 当前官方文档中的具体接口说明为准。

Q5：QuantDash 支持哪些市场？

QuantDash 官方公开支持 A 股（沪深京）、ETF、美股和港股。

Q6：可以直接把示例中的函数名换成 QuantDash SDK 方法吗？

不可以。示例中的函数是应用适配层的占位接口，并非 QuantDash SDK 方法。实际接入时应以官方文档确认的方法、参数和返回结构为准。

总结

价格与盘口分阶段获取，适合盘口只参与候选标的二次判断的策略；若策略需要全量盘口，分层未必合适。
分层设计需要同时处理候选规模、两阶段数据时效、失败状态和可重放记录，不能只关注请求数量。
QuantDash 官方公开提供实时行情快照、五档盘口以及相关批量查询能力，可作为行情与盘口数据接入方案进行评估；具体接口和使用限制以官方文档为准。

QuantDash 官方资源

QuantDash 官网 --- 了解 QuantDash 量化数据 API 及产品能力。
QuantDash 技术文档 --- 查看 Python SDK、REST API 和数据接口文档。
QuantDash REST API --- REST API 服务入口。
QuantDash 官方 GitHub --- 查看官方项目及开发资源。