1. 行情流消费场景与WebSocket定位
在数字资产交易、证券行情、外汇报价等场景中，价格不是"查一次就完事"的静态数据，而是持续变化的事件流。一个 BTC/USDT 现货行情，在活跃时段每秒可能产生数十到数百次盘口与成交更新；如果把这些更新当作"需要不断重新查询的资源"，系统设计就会天然落后于市场。因此，本课程的第一件事不是写代码，而是把"行情流消费"这件事的对象、通道和边界想清楚。
实时行情推送的业务需求
行情消费方的需求可以归纳为三类，它们对通道的要求并不相同：
- 时效性：从交易所撮合产生成交，到策略或界面看到该成交，延迟要尽可能低。做市、套利、风控强平监控对延迟尤其敏感，通常要求端到端在百毫秒级。
- 连续性：行情是"增量 + 快照"的组合。订阅后先拿到一份盘口快照，再持续接收增量更新；中间断流会导致本地盘口与交易所不一致，因此需要断线重连与快照重建机制。
- 多路复用：一个连接往往同时订阅多个交易对、多个频道（深度、成交、K 线、标记价格）。通道要支持在一个长连接上按主题分发消息，而不是为每个标的开一条连接。
与之相对，如果采用"客户端定时问服务器要最新价"的模式，时效性受轮询间隔限制，连续性靠每次全量拉取保证，多路复用则退化为多次请求。这正是需要引入推送型通道的根本原因。
WebSocket 与 HTTP 轮询、SSE 的对比
三种常见方案的本质差异在于"谁发起数据传递"以及"连接是否长期保持"：
| 维度 | HTTP 短轮询 | SSE（Server-Sent Events） | WebSocket |
|---|---|---|---|
| 连接形态 | 每次请求新建，短连接 | 单个长连接，HTTP 响应流 | 单个长连接，握手后升级为全双工 |
| 数据方向 | 客户端拉，服务器答 | 服务器单向推送 | 双向，客户端可发订阅/心跳 |
| 典型延迟 | 受轮询间隔约束，通常秒级 | 较低，事件到达即推 | 低，事件到达即推 |
| 协议开销 | 每次请求带完整头部 | 文本事件流，头部仅握手一次 | 握手后为轻量帧，开销小 |
| 适用场景 | 低频、非实时查询 | 单向通知、行情看板 | 需动态订阅、双向交互的行情流 |
对行情消费而言，关键区别在于订阅是动态的：策略可能中途增加交易对、切换频道、调整深度档位。SSE 只能由服务器单向推送，客户端要改变订阅往往得重建连接或另走 HTTP 接口；WebSocket 则允许在已建立的连接上直接发送订阅消息，服务器按主题回推，天然契合"一个连接、多主题、可增删"的行情消费模型。因此本课程选择 WebSocket 作为行情流通道。
典型交易所行情流协议概览
主流交易所的 WebSocket 行情接口在细节上不同，但骨架高度一致，理解这个骨架后迁移成本很低：
- 连接地址：通常按"现货/合约""公共/私有"拆分不同 URL，例如公共行情流与账户私有流分开，避免权限混用。
- 订阅消息：客户端发送 JSON，形如
{"method":"SUBSCRIBE","params":["btcusdt@depth@100ms","btcusdt@trade"],"id":1}，用id关联应答。 - 推送消息：服务器回推带
stream或e（事件类型）字段的 JSON，如深度更新depthUpdate、逐笔成交trade、K 线kline。 - 快照与增量：深度频道一般先给快照，再给带序号（如
U/u或lastUpdateId）的增量，消费方需按序号拼接。 - 心跳与限频：多数协议要求客户端定期发 ping 或依赖服务器 ping，长时间无消息需主动重连；订阅数量与消息速率有上限。
这些字段名在不同交易所会有差异，但"订阅—快照—增量—序号—心跳"这条主线是通用的。本课程示例以这条主线为教学对象，不绑定某一家交易所的私有细节。
本课程示例的边界与目标
为避免示例变成"某个交易所 SDK 的使用说明"，需要明确边界。范围内：建立并维持一条 WebSocket 连接；发送订阅、解析推送；用序号把快照与增量拼成一致的本地盘口；处理心跳、断线重连与重订阅；把解析后的行情以回调或队列形式交给下游策略。示例参数采用合理假设，例如订阅 btcusdt@depth@100ms 与 btcusdt@trade，本地维护前 20 档盘口，重连退避从 1 秒起、上限 30 秒。
范围外：交易所鉴权与私有账户流、历史数据回补、撮合与下单、生产级多活容灾。这些会在后续章节按需展开，但第一章先把"消费一条公共行情流"这件事做扎实。
把上述内容收束成一句话：行情流消费的本质是"在一条可双向通信的长连接上，按主题持续接收增量，并用序号与快照保证本地状态正确"。WebSocket 之所以成为默认选择，不是因为它新，而是因为它在时效性、连续性和动态订阅三方面同时满足行情场景的要求。接下来的章节将围绕这条主线，从连接建立、订阅管理、消息解析到盘口重建逐步展开。