频率与配额

WebSocket 行情推送会按账号、连接、订阅标的、订阅类型和行情权限进行配额与权限校验。配额用于保护长连接服务稳定性，也用于确保不同权限档位的用户只能订阅其已开通的行情能力。

INFO

具体配额数量与账号类型、行情权限、产品套餐、市场和品类有关。本文说明配额的计算口径和客户端处理建议，不提供固定数值限制。请以账号实际权限、接口返回和产品配置为准。

配额类型

类型	说明	客户端建议
连接配额	限制同一账号或同一应用可同时保持的 WebSocket 长连接数量。超过限制时，新连接、登录鉴权或后续订阅可能失败。	复用连接承载多个标的和多个数据类型，避免为每个标的单独建立连接。
订阅配额	限制同一账号当前可保持的订阅项总量。订阅项通常由“标的 + 数据类型”组成，K 线还会包含周期和复权方式。	页面退出、标的切换或不再展示某类行情时，及时发送反订阅请求释放配额。
权限配额	行情权限决定是否可订阅某市场、品类和数据深度，例如买卖盘档数、深度摆盘、经纪队列等。	订阅前确认用户已开通对应市场与行情档位；收到权限错误时引导用户开通或降级订阅。
频率限制	服务端可能限制鉴权、订阅、反订阅、重连等控制消息的发送频率。	合并批量订阅请求，避免在短时间内反复订阅和反订阅同一标的。

连接配额

WebSocket 是长连接能力，连接数本身也会消耗服务端资源。客户端应尽量采用“少连接、多订阅”的方式：

同一业务页面优先复用一个 WebSocket 连接。
同一连接内可以订阅多个标的和多个行情类型。
不建议因为标的数量增加而线性增加连接数。
多窗口、多设备同时在线时，应考虑账号级连接上限可能被共同占用。
连接断开后应重新连接、重新登录鉴权并重新订阅，不要假设旧连接上的订阅状态仍然有效。

如果客户端需要同时运行在多个页面或多个进程中，建议在应用层统一管理连接，避免每个组件各自创建 WebSocket。

订阅配额

订阅配额按账号维度统计当前仍然有效的订阅项。一次订阅请求中，不同数据类型会分别占用订阅资源，例如：

quote：基础报价订阅。
order_book：买卖盘订阅。
ticker：逐笔成交订阅。
kline：K 线订阅，通常还会按 period 和 adjust 区分不同订阅项。

服务端内部会使用账号维度的总配额进行校验。该总配额在后端链路中可称为 uid_total_quota，表示当前用户可使用的全局订阅总额度。它由登录态、账号权限或上游网关注入，不是客户端应自行填写或伪造的公开请求字段。

WARNING

不要依赖固定的公开配额数字，也不要假设某一类订阅一定不占用配额。不同环境、权限档位和服务端版本的计数规则可能不同，尤其是 K 线是否计入总订阅配额，应以生产环境实际返回和产品规则为准。

配额超限错误

当新增订阅会超过账号可用订阅总额度时，订阅请求会失败。若网关直接透传订阅响应，常见响应语义如下：

字段	说明
`id`	对应客户端请求中的 `id`，用于匹配请求与响应。
`code`	结果码，`0` 表示成功。
`message`	错误说明。

配额超限时，服务端可能返回：

json

{
  "id": "sub-001",
  "code": 4,
  "message": "sub quota exceeded, max=..."
}

其中 code = 4 表示订阅配额不足或超过最大订阅数。客户端收到该错误后，不应立即高频重试；应先减少当前订阅项，或提示用户升级权限/套餐后再重试。

INFO

公开 WebSocket 网关可能会对错误响应做包装或翻译。请以实际返回字段为准，但排查配额问题时可以重点关注“quota exceeded”“sub quota exceeded”以及错误码 4。

买卖盘深度与权限

order_book 买卖盘订阅不仅受订阅总量限制，还受行情权限档影响。不同市场、品类和权限档位可能返回不同深度：

LV1 权限通常只能获得基础档位或有限深度。
LV2/LV3 等更高权限可能支持更多档位或深度摆盘。
部分港股品类可能同时具备经纪队列能力，对应推送 BROKER_QUEUE。
未开通对应市场或深度权限时，订阅可能失败，或只能返回较低档位的数据。

因此，客户端不应仅根据订阅请求是否包含 order_book 来假设一定能收到完整深度摆盘。展示层应根据实际推送内容、数组长度和字段缺省情况进行兼容处理。

逐笔成交批量推送

ticker 逐笔成交可能按批次合并推送，而不是每一笔成交都单独发送一条 WebSocket 消息。客户端应按 ticker_list 数组处理一批成交记录：

不要假设一条 TICKER 消息只包含一笔成交。
应按 sequence、time_ms 等字段做去重、排序或增量合并。
UI 渲染应做节流，避免每收到一批数据就触发高成本全量重绘。
如果断线期间需要补齐最新成交，可在重连后结合 REST 逐笔成交接口查询。

订阅与反订阅最佳实践

合并请求

尽量把同一时刻需要订阅的标的和类型合并到一次请求中发送。例如页面初始化时，一次性订阅当前可见列表的 quote，而不是为每个标的各发送一次订阅请求。

按可见范围订阅

对于大列表、滚动表格或自选股分组，建议只订阅当前页面需要展示的标的：

用户切换分组时，反订阅旧分组不再展示的标的。
列表滚动时，可以按窗口范围增量订阅和反订阅。
后台页面或隐藏 Tab 可降低订阅规模，必要时只保留关键标的。

及时释放配额

当用户关闭页面、切换标的、取消关注或不再需要某类行情时，应主动发送 unsubscribe：

反订阅成功后，对应订阅项才会释放配额。
同一账号在其他连接或设备上仍持有相同订阅时，账号级配额可能不会立即减少到 0。
连接异常断开后，服务端会清理离线会话，但客户端不应依赖清理延迟来释放配额。

避免订阅抖动

以下行为容易触发频率限制或造成配额抖动：

用户每输入一个字符就重新订阅搜索结果。
在短时间内对同一标的反复订阅和反订阅。
网络不稳定时多个连接同时自动重连并全量重订阅。
因 UI 重渲染导致重复发送相同订阅请求。

建议在客户端加入防抖、去重和状态机：只有当目标订阅集合发生变化时，才发送增量订阅或反订阅请求。

重连后分批恢复

断线重连后需要重新登录鉴权并恢复订阅。若订阅集合较大，建议：

先恢复页面当前可见或业务最关键的标的。
再分批恢复其他标的。
每批请求之间保留短暂间隔，并处理失败重试。
对配额超限、权限不足、标的无效等错误做分类处理，不要无限重试。

降级策略

当订阅失败或配额不足时，客户端可以按业务重要性降级：

优先保留当前屏幕可见标的。
优先保留 quote 基础报价，减少 order_book、ticker 或多周期 kline 订阅。
买卖盘深度权限不足时，降级展示可用档位或提示用户开通权限。
对低优先级标的改用 REST 低频轮询。

排查建议

遇到配额或频率相关问题时，可以按以下顺序排查：

确认 WebSocket 已完成登录鉴权。
检查订阅请求中的标的代码、数据类型、K 线周期和复权方式是否有效。
检查是否存在重复订阅、未反订阅或多个页面共享账号占用配额。
查看订阅响应中的 id、code 和 message，重点关注 code = 4 或 quota 相关提示。
检查用户是否具备对应市场、品类和买卖盘深度权限。
对大批量订阅场景，降低单批订阅数量并增加重试退避。

频率与配额 ​

配额类型 ​

连接配额 ​

订阅配额 ​

配额超限错误 ​

买卖盘深度与权限 ​

逐笔成交批量推送 ​

订阅与反订阅最佳实践 ​

合并请求 ​

按可见范围订阅 ​

及时释放配额 ​

避免订阅抖动 ​

重连后分批恢复 ​

降级策略 ​

排查建议 ​

相关文档 ​