被忽视的8.5小时：美股夜盘数据的价值

大部分量化团队每天都在用不完整的数据做决策

美股每个交易日有四个交易时段：盘前、正盘、盘后、夜盘。这不是什么新知识。

但一个值得注意的事实是：我们接触到的量化团队中，相当一部分的行情系统只接入了正盘的6.5小时。剩下的盘前4小时、盘后4小时、夜盘4.5小时——合计每天8.5小时的交易数据，在策略的信号链条里是空白的。

这8.5小时里发生的事：财报集中发布、宏观数据落地、亚太资金在美股的重新定价——它们对次日开盘价的影响，被这些系统视而不见。

一、策略信号为什么总在开盘跳空

先看一个典型的回测场景：你的策略在收盘时发出买入信号，次日开盘以市价单成交。回测曲线很平滑，但实盘上线后，开盘价经常偏离信号价格1.5%以上。

问题不在策略逻辑，在数据源。

美股上市公司的财报绝大部分在盘后时段（16:00-20:00 ET）发布。根据近三年的统计，标普500成分股中超过85%的财报落地在盘后窗口。这意味着：当一个策略只看正盘数据做决策时，它完全不知道盘后发生了什么——是利好还是利空——直到第二天开盘，价格已经跳完了。

这不是预测能力的问题，是信息输入完整度的问题。

更进一步，对于配置了美股仓位的亚太机构，夜盘时段（20:00-4:00 ET，对应北京时间8:00-16:00）是唯一可以同步交易的窗口。亚太交易员对美股的反应，首先体现在夜盘成交量上。如果策略系统不接入夜盘数据，相当于把其他市场参与者对美股的定价意见排除在模型之外。

二、四个时段，四种信息结构

美股全天24小时并非铁板一块。四个时段在参与者结构、信息密度和流动性特征上差异显著。从量化团队的视角来看，理解这种差异比理解单个品种的K线形态更重要。

\*夜盘时长因经纪商和交易所不同存在差异，常规覆盖约4-4.5小时。

几个值得展开的点：

盘后是信息密度最高的时段。 Q3财报季期间，盘后的订单簿深度变化幅度是正盘时段的2-3倍。一个订单簿从45档骤降到9档的信号，在正盘可能意味着系统性风险，在盘后则大概率是流动性撤退——两者在策略里应该触发完全不同的应对逻辑。但如果策略不区分时段，它们看起来是同一个信号。

💡 深度解析：盘后的"流动性真空"陷阱

为什么在盘后即使只有极小的成交量也能拉出5%的涨幅？

利用行情数据的 depth 接口，你会观察到正盘时段 bids（买盘）和 asks（卖盘）的分布极其紧密（Tight Spread）。但在财报发布后的盘后窗口，做市商通常会撤单以避险。此时订单簿会出现严重的"微观结构失衡"（Order Book Imbalance）。

这种流动性缺失导致了价格发现的非线性。一个在正盘时段只能引发1个基点波动的市价单，在盘后可能会瞬间击穿5档深度。如果你的策略不读取 trade_session 字段并动态调整冲击成本模型，你的回测曲线在这一刻就已经失真了。问题的核心不是"拿到了数据"，而是策略是否知道自己拿到的数据处于什么市场状态。

夜盘是亚太资金的定价窗口。 我们在数据中观察到一个规律：美股夜盘时段的成交量中，与中国概念相关的品种（中概股、大宗商品ETF、港美联动标的）的成交占比明显高于正盘时段。这不是偶然——它是亚洲交易员在用自己的资金表达对美股的观点。对于一个管理多市场组合的团队来说，夜盘数据不是"锦上添花"，是理解跨市场资金流向的必要输入。

盘前是信息传导的缓冲带。 亚太市场收盘后的波动、欧洲早盘的宏观数据，会先反映在美股盘前期货和ETF上。把这5.5小时排除在模型之外，等于放弃了一个事先校准当日策略方向的机会。

三、一套接口，统一字段，自动区分时段

从工程实现的角度，不同时段的数据获取其实可以收敛到一个简单的接口层。关键是服务端是否已经在数据中做了时段标记。

TickDB 的逐笔成交（trades）数据中，每笔成交都带有一个 trade_session 字段，以整数枚举值标记该笔成交所属的时段：0（正盘）、1（盘前）、2（盘后）、3（夜盘）。对于策略代码来说，不需要自己维护一套时段映射表，也不用在不同数据源之间做字段对齐。

以下是一个获取全时段逐笔成交的简化示例，包含完整的心跳保活和断线重连机制：

import os
import asyncio
import websockets
import json

API_KEY = os.environ.get("TICKDB_API_KEY")
# WebSocket 端点：v1/realtime
WS_URL = f"wss://api.tickdb.ai/v1/realtime?api_key={API_KEY}"

# trade_session 整数枚举
SESSION = {0: "regular", 1: "pre_market", 2: "after_hours", 3: "overnight"}

async def subscribe_all_sessions(symbols: list[str]):
    reconnect_delay = 1.0
    max_delay = 30.0

    while True:
        try:
            async with websockets.connect(
                WS_URL, ping_interval=1, ping_timeout=5
            ) as ws:
                reconnect_delay = 1.0  # 连接成功，重置退避

                # 订阅逐笔成交频道
                await ws.send(json.dumps({
                    "cmd": "subscribe",
                    "channel": "trades",
                    "symbols": symbols
                }))

                # 启动心跳监听任务
                async def heartbeat():
                    while True:
                        await ws.send(json.dumps({"cmd": "ping"}))
                        await asyncio.sleep(1)

                asyncio.create_task(heartbeat())

                # 接收推送数据
                async for msg in ws:
                    trade = json.loads(msg)
                    session_code = trade.get("trade_session", 0)
                    # 整数枚举判断：0=正盘, 1=盘前, 2=盘后, 3=夜盘
                    if session_code == 2:
                        on_after_hours_trade(trade)
                    elif session_code == 3:
                        on_overnight_trade(trade)
                    else:
                        on_regular_trade(trade)

        except Exception:
            await asyncio.sleep(reconnect_delay)
            reconnect_delay = min(reconnect_delay * 2, max_delay)

这段代码的核心是服务端标准化，不是客户端逻辑。

大部分开发者拿到行情数据后做的第一件事，就是写一个工具函数把美东时间戳转成北京时间，再映射到对应的交易时段。这个函数最终会膨胀到几百行：夏令时切换规则、交易所半天交易日、节假日日历、不同品种的时段差异——每个细节都是一个潜在的 bug。

trade_session 字段的价值在于：它把"判断这笔成交发生在哪个时段"这件事从客户端职责变成了服务端职责。你不需要理解美东时间的夏令时规则，不需要为港股的午休时段单独写逻辑，字段在到达你的策略引擎之前已经完成了标准化的整数映射。一套判断逻辑，覆盖全品种，这是工程上真正的便利性所在。

四、"接入了行情"和"接入了全时段行情"是两件事

为美股、港股、加密分别维护三套时段判断逻辑、三套字段适配层、三套断线重连机制——这是大多数多市场量化团队的现状。

问题不在于数据源贵不贵，在于维护成本会随市场数量线性增长。美股有四个时段，港股有两个，加密是7×24。每个市场的时段定义、交易所规则、节假日日历都在变化。一个量化工程师每季度花35个小时维护这些对接逻辑，这不是估算，是我们从多家客户那里听到的真实数字。

TickDB 的 trade_session 枚举值在服务端统一维护，以整数形式返回：0（正盘）、1（盘前）、2（盘后）、3（夜盘）。客户端不需要理解美东时间的夏令时规则，不需要为港股的午休时段单独写逻辑，不需要判断加密永续合约的结算时间戳是否对齐。字段在到达你的策略引擎之前，已经完成了标准化。

"接入了美股行情"和"接入了美股全时段行情"，这两件事之间的差距，在策略上线第一天并不明显，但会在第一次错过财报窗口时显现。

五、写在最后

本文没有提供一个具体的交易策略。我们的判断是：在数据输入层缺了每天8.5小时的信息时，讨论策略细节的意义有限。

真正值得每个量化团队复盘的问题是：你的当前系统获取的数据，覆盖了几个交易时段？盘后和夜盘的数据，是存储在数据库里等待分析，还是实时进入了信号计算链路？

欢迎在留言区分享你的团队在跨时段数据处理上的实践。我们会在后续文章中选取有代表性的问题做展开分析。

📡 数据由 TickDB.ai 提供

通过 TickDB API 获取实时行情数据

一个 API 接入外汇、加密货币、美股、港股、A股、贵金属和全球指数的实时行情。支持 WebSocket 低延迟推送，免费开始使用。