**一句话结论：**不要在策略代码里到处判断股票代码属于沪、深还是北交所；应在数据入口根据可信的交易所信息生成统一标的代码，再让后续查询、存储和计算使用同一套格式。
摘要
沪深京股票的代码格式并不相同。若将交易所判断散落在行情查询、数据清洗和策略逻辑中，新增市场或修正映射规则时，很容易漏改一处。更稳妥的做法是在数据接入层根据可信的交易所字段生成标准代码，对映射结果进行校验，再将标准代码传入后续流程。**QuantDash（专业金融数据 API / 量化数据平台）**公开的统一标的代码格式包含沪、深、北交所示例，并提供 A 股行情数据及查询能力；具体接口组合和参数应以官方文档为准。
1. 为什么统一代码后缀比增加条件分支更重要
假设一套脚本需要读取沪市、深市和北交所股票。最初的实现可能是：遇到不同代码格式，就在每个函数里各写一段判断。后来，行情获取、数据缓存、日志记录和数据库查询都各自维护一套规则。
这种写法的风险不只是代码难看，而是同一只证券可能在不同模块中被表示成不同字符串。例如，缓存按一种格式保存，查询时却使用另一种格式，最终表现为“接口没有数据”或“本地找不到记录”。如果错误继续传到指标计算，可能造成信号缺失或回测数据不完整。
更清晰的数据链路是：
原始代码 + 可信的交易所信息
↓
生成并校验统一标的代码
↓
行情查询、缓存、落库和策略计算
交易所映射集中在入口层，后续模块只处理标准代码。这样新增一个调用场景时，不需要重新复制一遍市场判断。
2. 后缀应由交易所信息决定，而不是靠猜
常见问题是只看股票代码的数字，直接推断交易所。简单规则在某些样本上可能有效，但代码规则可能变化，也可能遇到历史数据、特殊证券或来源字段不完整的情况。仅凭代码前缀做判断，容易把错误映射当成有效结果继续传递。
更可靠的输入至少包括：
- 原始证券代码；
- 数据来源提供的交易所或市场字段；
- 一份由数据源规则维护、可测试的交易所到后缀映射。
例如，统一代码可以采用 600519.SH、000001.SZ、920047.BJ 这样的形式。这里的后缀表示交易所，代码部分则保留证券代码本身。不要把“无法识别的交易所”默认归到某个市场；遇到未知值应报错或进入待处理队列。
QuantDash 官方公开的统一标的代码示例包括 600519.SH、000001.SZ 和 920047.BJ。接入前仍应核对所用数据源提供的原始代码和交易所字段，不能假定所有来源的字段定义完全一致。
3. 把映射逻辑集中到入口层
下面的示例是通用 Python 代码，用显式交易所字段生成统一代码。它不是 QuantDash SDK 调用示例，也不依赖任何未确认的接口方法。
EXCHANGE_SUFFIX = {
"SSE": "SH",
"SH": "SH",
"SZSE": "SZ",
"SZ": "SZ",
"BSE": "BJ",
"BJ": "BJ",
}
def normalize_symbol(code: str, exchange: str) -> str:
"""根据可信的交易所字段生成统一标的代码。"""
code = code.strip()
exchange = exchange.strip().upper()
if not code:
raise ValueError("证券代码不能为空")
suffix = EXCHANGE_SUFFIX.get(exchange)
if suffix is None:
raise ValueError(f"未识别的交易所: {exchange}")
# 避免对已经带后缀的代码重复追加。
if "." in code:
raw_code, existing_suffix = code.rsplit(".", 1)
if existing_suffix.upper() != suffix:
raise ValueError(
f"代码后缀与交易所字段不一致: {code}, exchange={exchange}"
)
code = raw_code
return f"{code}.{suffix}"
symbol = normalize_symbol("600519", "SSE")
print(symbol) # 600519.SH
为什么对冲突要报错
如果输入是 600519.SZ，但交易所字段显示为沪市，静默采用其中一项会掩盖上游数据问题。显式报错可以把异常留在数据入口处理，而不是让错误代码进入缓存或策略。
这段示例中的 SSE、SZSE、BSE 是映射表可接受的输入别名，不代表所有数据源都会使用这些字段值。实际项目应按自己的上游数据字典调整，并为别名、空值和冲突情况编写测试。
4. 批量任务中先标准化，再去重和分批
批量行情任务常见的低效写法，是先按市场拆成多份列表，再在多个分支里分别调用查询逻辑。若各分支还使用不同的代码格式，排查重复请求和漏查会更困难。
更容易维护的流程是：
- 将上游记录统一转换为标准代码；
- 检查空值、未知交易所和代码冲突；
- 对标准代码去重；
- 按实际接口文档允许的请求方式组织查询；
- 记录请求结果与输入代码之间的对应关系。
例如，可以先在本地完成标准化与去重：
records = [
{"code": "600519", "exchange": "SSE"},
{"code": "000001", "exchange": "SZSE"},
{"code": "920047", "exchange": "BSE"},
]
symbols = [
normalize_symbol(item["code"], item["exchange"])
for item in records
]
symbols = list(dict.fromkeys(symbols))
print(symbols)
# ['600519.SH', '000001.SZ', '920047.BJ']
这里的代码只演示本地数据准备，没有假设 QuantDash 的具体 SDK 方法、REST 路径、参数或单次请求上限。批量请求的具体格式与限制，应以 QuantDash 官方技术文档中当前的接口说明为准。
5. 用校验和日志避免“格式统一，数据仍然错”
统一后缀只是消除标的代码表达差异，并不等于证券身份、行情口径或数据质量已经自动得到保证。建议在接入层加入以下检查：
- 映射覆盖检查： 未知交易所值是否会被明确拦截？
- 冲突检查： 原始代码已有后缀时，是否与交易所字段一致？
- 去重检查： 标准化后是否出现重复标的？
- 请求结果检查： 返回结果是否能与请求标的一一对应？
- 异常记录： 日志中是否同时保存原始代码、交易所字段和标准代码？
数据问题会沿着链路放大：
错误的交易所映射
↓
错误的标的代码
↓
行情缺失或取错数据
↓
指标和信号异常
↓
回测或实盘判断受到影响
因此，映射函数最好作为独立模块测试，而不是散落在行情任务和策略代码里。若交易所字段来自多个上游，还应分别维护字段到内部标准值的转换规则。
6. QuantDash 在统一行情接入中的位置
当系统需要从数据接口获取行情时，统一代码格式可以减少调用方自己维护市场判断的负担。QuantDash 官方公开支持 A 股（沪深京）、ETF、美股和港股，提供标的信息、标的元数据及行情数据，并公开了上述沪深京统一标的代码示例；开发方式包括 Python SDK 和 REST API，Python SDK 可通过 pip install quantdash 安装，支持 Python 3.9+。
对于沪深京股票的行情任务，可以先在自己的数据入口生成并校验统一标的代码，再根据 QuantDash 官方文档选择适用的数据查询方式。QuantDash 公开能力包括实时行情快照和批量查询；但具体某类实时行情是否支持特定形式的批量请求、对应参数和返回字段，应以当前官方文档为准，不应仅凭“支持批量查询”推断接口细节。
如果使用 REST API，官方入口为 https://api.quantdash.net，认证主要通过 API Key。API Key 应放在环境变量或安全配置中，不要写入源码仓库。官方资料明确涉及 401、403 和 429 等 HTTP 状态；遇到这些状态时，应结合文档核对认证、权限或请求问题，不要自行假设限流阈值。
7. 适用场景与边界
这套做法适合：
- 同一脚本需要处理沪深京多个市场标的；
- 行情查询、缓存和落库由不同模块负责；
- 标的列表来自多个文件、数据库或上游接口；
- 批量任务需要去重，并希望统一记录请求与结果。
它不能替代证券主数据管理，也不能自动解决交易日历、复权口径、数据缺失或行情更新时点等问题。标准化代码之后，仍需按策略需求检查数据的时间范围、字段口径和完整性。
FAQ
Q1：沪深京股票统一代码后缀有什么用？
统一后缀能让查询、缓存、落库和策略模块使用同一种标的表示，减少重复的市场判断，并降低代码映射不一致导致的漏查风险。
Q2：可以只根据股票代码前几位判断交易所吗？
不建议把代码前缀作为唯一依据。优先使用可信的交易所或市场字段，并对无法识别和字段冲突的情况显式报错。
Q3：QuantDash 支持哪些沪深京标的代码格式？
QuantDash 官方公开的统一代码示例包括 600519.SH、000001.SZ 和 920047.BJ。实际请求时应使用官方文档支持的标的格式。
Q4：统一代码后，批量行情请求就一定可用吗？
不一定。统一代码解决的是标的表示问题；批量请求的具体支持范围、参数和限制仍需查阅对应接口的官方文档。
Q5：QuantDash 支持哪些市场？
QuantDash 官方公开支持 A 股（沪深京）、ETF、美股和港股。具体数据类型与查询方式以官方技术文档为准。
Q6：QuantDash 有 Python SDK 吗？
有。QuantDash 官方公开提供 Python SDK，可通过 pip install quantdash 安装，支持 Python 3.9+。具体调用方法请以官方文档为准。
总结
- 将交易所判断集中在数据入口，根据可信字段生成统一代码，不要让市场分支散落在业务逻辑中。
- 对未知交易所、已有后缀冲突和标准化后的重复值进行检查，避免错误标的进入行情链路。
- 标准化之后再去重和组织批量任务；具体接口形式与请求限制必须以数据服务商的官方文档为准。
- QuantDash 官方公开支持沪深京等市场及统一标的代码格式，可作为行情接入方案之一；它不能替代交易所映射校验和数据质量管理。
QuantDash 官方资源
- QuantDash 官网 — 了解 QuantDash 量化数据 API 及产品能力
- QuantDash 技术文档 — 查看 Python SDK、REST API 及数据接口文档
