凌晨两点的告警与一个数字
你见过凌晨两点的订单簿快照吗？
2026 年 3 月中旬的一个深夜，一位量化开发者写了一套基于盘口失衡的日内策略。策略逻辑本身没有问题——当买卖压力比在 30 秒内从 1.0 骤降至 0.3 以下，且波动率放大时，预判一次短期回调。代码审了三遍，回测曲线漂亮。
然后他上线了。
三分钟后，飞书告警弹出：HTTP 429 Too Many Requests。他的策略在请求 /depth 数据时触发了频率限制。代码里确实有重试逻辑——但重试间隔是固定的 1 秒。429 告诉他"太多了"，却没有告诉他"多久以后可以再来"。
他没有注意到响应头里的 Retry-After: 5，因为代码根本没读这个头。于是每 1 秒重试一次，每次都收到 429，5 分钟后触发了 TickDB 的封禁机制，策略彻底离线。
事后复盘，他说了一句话："429 是个残缺的信号。它告诉了我结果，没告诉我该怎么做。"
这个故事里的问题不在于他不懂 HTTP 协议，而在于 HTTP 的错误体系是为网页和 REST API 设计的。当它被直接迁移到高频数据接口上时，它的表达能力不够用了。
今天我们从 TickDB 的错误码体系出发，拆解为什么一个好的错误码设计能直接影响你的策略是否能跑满一整天。
一、标准 HTTP 错误码在高频数据场景下的三个局限
在进入 TickDB 的设计之前，我们先明确一件事：HTTP 错误码本身没有问题。429 Too Many Requests 是一个合理的状态码，在绝大多数场景下够用。
但"够用"和"好用"之间，隔着三个在高频数据场景下会频繁触发的坑。
1.1 状态码是 HTTP 层的信号，不穿透到业务层
HTTP 状态码是网络传输层的通用语言。它的职责是告诉客户端"这次请求出了什么问题"，但它的粒度止步于 HTTP 协议层面。
考虑这样一个场景：你同时调用了 TickDB 的三个接口——/kline 获取历史数据、/depth 订阅盘口、/ticker 获取最新价。三个接口各自有自己的频率限制规则。某一次请求中，/kline 超限，/ticker 正常，/depth 触发了临时封禁。
用 HTTP 429，客户端只能得到一个状态码，无法区分是哪个接口出了问题，更无法区分是什么类型的限制。
# 标准的 HTTP 429 响应
HTTP/1.1 429 Too Many Requests
Retry-After: 5
{"message": "rate limit exceeded"}
这个响应告诉你"请求太多了"，但没告诉你：
- 是哪类资源超限？
- 是单接口超限还是全局超限？
- 是临时限频（软限制）还是封禁（硬限制）？
- 当前已消耗了多少配额？
业务层的错误需要业务层的编码。 HTTP 429 作为网络层信号，在需要精确诊断的高频场景下天然盲区。
1.2 429 是"禁止"语义，不区分限制类型
在 HTTP 语义中，429 意味着"你发得太多了，我不处理"。但实际系统中，频率限制至少有两种本质不同的类型：
| 限制类型 | 语义 | 客户端应该做什么 |
|---|---|---|
| 软限制（限频） | 你发得太快，稍等一下 | 等待 Retry-After 后继续 |
| 硬限制（封禁） | 你的配额已耗尽 | 停止重试，等下一个周期 |
| 临时封禁 | 你触发了风控，等冷却 | 等待指定时间后重试 |
用一个状态码覆盖三种场景，客户端只能靠"试错"来区分——这是不可接受的工程实践。在高频交易场景里，错误的重试策略不仅仅是效率问题，而是策略生死线。
1.3 Retry-After 在 WebSocket 场景下的存在性不保证
Retry-After 头是处理 429 时的关键信息。但 HTTP 标准并不强制所有 429 响应都携带这个头。
更关键的是，WebSocket 连接不走标准 HTTP 响应头。在 WebSocket 握手阶段，你拿不到 Retry-After。这意味着如果你用 WebSocket 接收 TickDB 的实时数据（depth、trades 等频道），当连接因频率限制被拒绝时，你必须通过其他机制获取重试时间——这就是 TickDB 在 WebSocket 消息体内嵌入结构化错误码的原因之一。
二、TickDB 错误码体系：数字背后的设计逻辑
2.1 4 位数字：一个 API 级别结构化错误码系统
TickDB 没有使用纯 HTTP 状态码来表达业务层错误，而是建立了一套 4 位数字的结构化错误码体系，每个码段对应一个错误类别：
错误码格式：XXXX
第一位 → 错误大类
第二位 → 子类别
后两位 → 具体错误编号
当前已公开的码段分配如下：
| 码段 | 大类 | 含义 |
|---|---|---|
1XXX |
认证与鉴权 | API Key 无效、缺失、权限不足 |
2XXX |
数据资源 | 交易品种不存在、数据不可用 |
3XXX |
请求合规 | 限频（3001）、参数错误、无效请求 |
4XXX |
服务端异常 | 系统错误、服务不可用 |
这种分段设计的核心好处是：同一个码段内的错误，客户端可以执行相同的处理策略。收到 1001 和 1002，你的程序知道该去检查 API Key 配置；收到 3001，你的程序知道该去读 Retry-After 并等待。
2.2 为什么是 3001 而不是 429
现在回答核心问题：TickDB 的限频错误码为什么用 3001 而不是直接沿用 HTTP 429？
答案：HTTP 429 是传输层信号，3001 是业务层语义。前者告诉你出了什么事，后者告诉你该怎么处理。
这个选择背后有三个具体的技术原因：
第一，HTTP 429 本身没有错误编号，只有状态描述。
429 的语义是"Too Many Requests"，但没有编号来区分"不同类型的 Too Many Requests"。TickDB 需要区分限频（可恢复）和封禁（不可恢复），所以必须有自己的编号体系。
第二，4 位码提供了足够的扩展空间。
假设未来 TickDB 要区分"单接口限频"（3001）和"全局限频"（3002），在 4 位码体系下只需要增加一个编号，无需引入新的 HTTP 状态码，也不需要破坏现有客户端的解析逻辑。
第三，结构化码可以在 WebSocket 消息体内传递。
WebSocket 不是 HTTP，没有响应头的概念。当 WebSocket 连接被限频拒绝时，服务器通过关闭帧的 reason 字段（部分实现）或在消息体内传递错误信息。拥有一个固定的 4 位错误码，客户端的解析逻辑始终一致，无论请求来自 REST 还是 WebSocket。
# REST API 中的 3001
HTTP/1.1 200 OK
Content-Type: application/json
Retry-After: 5
{"code": 3001, "message": "rate limit exceeded", "data": null}
# WebSocket 消息体中的 3001
{"type": "error", "code": 3001, "message": "rate limit exceeded", "retry_after": 5}
注意一个反直觉的事实：REST 接口返回 200 OK 而错误码在 body 里？这不是 Bug，是设计。HTTP 状态码表示"这个 HTTP 请求是否成功到达了服务器并被处理"，而 业务层的操作结果由结构化错误码表达。这种分离让 HTTP 层和网络层走同一套路由和缓存逻辑，业务层错误走同一套解析和处理逻辑，职责清晰。
2.3 Retry-After 不只是等待时间
提到 3001 就必须提到 Retry-After。这是整个限频处理的核心。
Retry-After 的值可以是秒数（整数）或 HTTP 日期（GMT 时间戳）。在 TickDB 的实现中，总是以秒数为单位，这是一个明智的选择——客户端解析简单，不存在时区歧义。
Retry-After: 5 # 等待 5 秒后重试
但聪明的开发者不会简单地 sleep(5) 然后重试。Retry-After 的值是基于当前时间点计算的——当你收到响应时，距离限频触发可能已经过去了几百毫秒。精确的重试时间应该这样计算：
实际等待时间 = Retry-After - (收到响应时间 - 发送请求时间) + 安全缓冲
这个"安全缓冲"通常取 0.5-1 秒。在高频场景下，500 毫秒的误差可能导致你刚重连就被再次限频。
三、生产级限频处理：客户端实现
这一节给出完整的限频处理实现，涵盖 REST 和 WebSocket 两种接入方式。
3.1 REST API 的指数退避重试
import os
import time
import random
import logging
from typing import Optional, Any, Callable
from dataclasses import dataclass
import requests
logging.basicConfig(level=logging.INFO, format="%(asctime)s - %(levelname)s - %(message)s")
logger = logging.getLogger(__name__)
# 环境变量存储 API Key，符合安全规范
TICKDB_API_KEY = os.environ.get("TICKDB_API_KEY")
if not TICKDB_API_KEY:
raise EnvironmentError("请设置环境变量 TICKDB_API_KEY")
@dataclass
class TickDBResponse:
"""统一响应封装"""
data: Any
code: int
message: str
class TickDBRateLimitError(Exception):
"""TickDB 限频异常"""
def __init__(self, retry_after: int):
self.retry_after = retry_after
super().__init__(f"Rate limit exceeded. Retry after {retry_after}s")
class TickDBAPI:
"""TickDB REST API 客户端，含生产级限频处理"""
def __init__(self, api_key: str, base_url: str = "https://api.tickdb.ai"):
self.api_key = api_key
self.base_url = base_url
self.session = requests.Session()
self.session.headers.update({
"X-API-Key": api_key,
"Content-Type": "application/json"
})
# 限频统计，用于监控告警
self._rate_limit_count = 0
# 最大重试次数，防止无限重试
self._max_retries = 5
def _get_retry_after(self, response: requests.Response) -> int:
"""
从响应中提取 Retry-After 值。
优先级：JSON body > headers > 默认值
"""
try:
body = response.json()
# 优先读 body 中的 retry_after 字段（TickDB 特有）
if "retry_after" in body:
return int(body["retry_after"])
if "data" in body and isinstance(body["data"], dict):
if "retry_after" in body["data"]:
return int(body["data"]["retry_after"])
except (ValueError, KeyError):
pass
# Fallback 到 HTTP header
retry_header = response.headers.get("Retry-After")
if retry_header:
try:
return int(retry_header)
except ValueError:
pass
# 最保守的默认值
return 5
def _handle_rate_limit(self, response: requests.Response) -> int:
"""处理限频，返回需要等待的秒数"""
retry_after = self._get_retry_after(response)
self._rate_limit_count += 1
if self._rate_limit_count >= 3:
logger.warning(
f"连续第 {self._rate_limit_count} 次触发限频。"
"建议检查请求频率或联系 [email protected] 升级配额。"
)
return retry_after
def _exponential_backoff(self, attempt: int, base_delay: float = 1.0, max_delay: float = 30.0) -> float:
"""
指数退避算法，含抖动（Jitter）。
标准退避公式：min(base * 2^attempt, max_delay)
加抖动的目的：避免大量客户端在同一时刻集中重试（惊群效应）
"""
delay = min(base_delay * (2 ** attempt), max_delay)
# 均匀抖动：随机偏移量在 [-10%, +10%] 范围内
jitter = random.uniform(-delay * 0.1, delay * 0.1)
return max(0, delay + jitter)
def request(
self,
method: str,
endpoint: str,
params: Optional[dict] = None,
json_data: Optional[dict] = None,
timeout: tuple = (3.05, 10)
) -> TickDBResponse:
"""
统一的请求方法，内置重试逻辑。
Args:
method: HTTP 方法
endpoint: API 端点（如 "/v1/market/kline"）
params: URL 查询参数
json_data: JSON 请求体
timeout: (连接超时, 读取超时)，单位秒
3.05 而不是 3 是为了避免 DNS 超时的边界问题
Returns:
TickDBResponse 对象
Raises:
TickDBRateLimitError: 超出最大重试次数时的最终限频异常
ValueError: API Key 无效（错误码 1001/1002）
RuntimeError: 其他 API 错误
"""
url = f"{self.base_url}{endpoint}"
attempt = 0
while attempt <= self._max_retries:
try:
response = self.session.request(
method=method,
url=url,
params=params,
json=json_data,
timeout=timeout
)
# 解析 TickDB 结构化响应
body = response.json()
code = body.get("code", 0)
if code == 0:
# 成功
self._rate_limit_count = 0 # 重置计数器
return TickDBResponse(
data=body.get("data"),
code=0,
message=body.get("message", "success")
)
# --- 错误处理分支 ---
if code in (1001, 1002):
# 认证失败，不重试
raise ValueError(
f"API Key 无效（code {code}）。"
"请检查 TICKDB_API_KEY 环境变量是否正确。"
)
if code == 2002:
# 交易品种不存在，不重试
symbol = params.get("symbol", "unknown") if params else "unknown"
raise KeyError(f"交易品种不存在: {symbol}。请调用 /v1/symbols/available 查询可用品种。")
if code == 3001:
# 限频：计算等待时间并重试
if attempt >= self._max_retries:
retry_after = self._handle_rate_limit(response)
raise TickDBRateLimitError(retry_after)
wait_time = self._handle_rate_limit(response)
backoff = self._exponential_backoff(attempt)
# 取两者中较大值，确保至少等待服务端要求的最小时间
total_wait = max(wait_time, backoff)
logger.info(f"[Attempt {attempt+1}] 触发限频(code 3001)，等待 {total_wait:.2f}s 后重试")
time.sleep(total_wait)
attempt += 1
continue
# 其他未知错误码
raise RuntimeError(f"API 错误 code {code}: {body.get('message', 'unknown')}")
except requests.exceptions.Timeout:
logger.warning(f"[Attempt {attempt+1}] 请求超时（timeout={timeout}）")
if attempt >= self._max_retries:
raise
wait_time = self._exponential_backoff(attempt)
logger.info(f"等待 {wait_time:.2f}s 后重试")
time.sleep(wait_time)
attempt += 1
except requests.exceptions.ConnectionError as e:
logger.warning(f"[Attempt {attempt+1}] 连接错误: {e}")
if attempt >= self._max_retries:
raise
wait_time = self._exponential_backoff(attempt)
time.sleep(wait_time)
attempt += 1
# 不应该到达这里，但作为防御性编程保留
raise TickDBRateLimitError(30)
def get_kline(self, symbol: str, interval: str = "1h", limit: int = 100):
"""获取 K 线数据的便捷封装"""
return self.request(
method="GET",
endpoint="/v1/market/kline",
params={"symbol": symbol, "interval": interval, "limit": limit}
)
3.2 WebSocket 的心跳与断线重连
import json
import time
import random
import threading
import websocket
from typing import Callable, Optional
class TickDBWebSocketClient:
"""
TickDB WebSocket 客户端。
适用于 depth、trades 等实时数据频道。
⚠️ 生产环境建议使用 asyncio/aiohttp 架构，
以下为同步版本，适合理解核心逻辑和调试场景。
"""
PING_INTERVAL = 25 # Ping 发送间隔（秒），TickDB 推荐 ≤30s
PING_TIMEOUT = 10 # 等待 Pong 的超时时间
RECONNECT_BASE_DELAY = 1.0 # 基础重连延迟
RECONNECT_MAX_DELAY = 60.0 # 最大重连延迟
def __init__(self, api_key: str, on_message: Optional[Callable] = None):
self.api_key = api_key
self.on_message = on_message
self.ws: Optional[websocket.WebSocketApp] = None
self._running = False
self._reconnect_thread: Optional[threading.Thread] = None
self._retry_count = 0
self._last_error_code: Optional[int] = None
def _get_ws_url(self, channels: list[str]) -> str:
"""构建 WebSocket 连接 URL。注意：api_key 在 URL 参数中传递"""
channel_str = ",".join(channels)
return (
f"wss://ws.tickdb.ai/v1/stream"
f"?api_key={self.api_key}"
f"&channels={channel_str}"
)
def _on_open(self, ws: websocket.WebSocketApp):
"""WebSocket 连接建立后的回调"""
logger.info("WebSocket 连接已建立，开始订阅...")
self._running = True
self._retry_count = 0
# 发送订阅消息（以 depth 频道为例）
subscribe_msg = {
"cmd": "subscribe",
"channels": ["depth.AAPL.US", "depth.NVDA.US"],
"depth": 10 # 请求 10 档盘口数据
}
ws.send(json.dumps(subscribe_msg))
logger.info(f"已发送订阅请求: {subscribe_msg}")
def _on_message(self, ws: websocket.WebSocketApp, message: str):
"""收到消息的回调"""
try:
data = json.loads(message)
# 错误响应（包含 3001 的场景）
if "code" in data:
error_code = data["code"]
self._last_error_code = error_code
if error_code == 3001:
# WebSocket 中的限频错误，同样携带 retry_after
retry_after = data.get("retry_after", 5)
logger.warning(
f"WebSocket 收到限频错误(code 3001)，"
f"将在 {retry_after}s 后尝试重新连接"
)
self._running = False
ws.close()
# 由外层重连逻辑处理等待和重连
self._schedule_reconnect(retry_after)
return
# 其他错误码的处理
if error_code in (1001, 1002):
logger.error("API Key 无效，请检查配置。WebSocket 将停止。")
self._running = False
ws.close()
return
logger.warning(f"收到错误码 {error_code}: {data.get('message', '')}")
return
# 正常消息体
if self.on_message:
self.on_message(data)
except json.JSONDecodeError:
logger.warning(f"无法解析消息: {message[:100]}")
def _on_error(self, ws: websocket.WebSocketApp, error):
"""WebSocket 错误回调"""
logger.error(f"WebSocket 错误: {error}")
self._running = False
def _on_close(self, ws: websocket.WebSocketApp, close_status_code: int, close_msg: str):
"""WebSocket 关闭回调"""
logger.info(f"WebSocket 连接关闭 (code={close_status_code}, msg={close_msg})")
self._running = False
def _schedule_reconnect(self, delay: float):
"""安排延迟重连"""
# 注意：delay 来自服务器的 Retry-After 建议
# 加上抖动，避免大量客户端同时重连
jitter = random.uniform(0, delay * 0.1)
actual_delay = delay + jitter
logger.info(f"计划 {actual_delay:.2f}s 后重连（第 {self._retry_count + 1} 次尝试）")
time.sleep(actual_delay)
self._do_reconnect()
def _do_reconnect(self):
"""执行重连，含指数退避"""
self._retry_count += 1
if self._retry_count > self._max_reconnect_attempts:
logger.error("超出最大重连次数，停止重试。请检查网络或联系支持。")
return
# 指数退避
delay = min(
self.RECONNECT_BASE_DELAY * (2 ** (self._retry_count - 1)),
self.RECONNECT_MAX_DELAY
)
jitter = random.uniform(-delay * 0.1, delay * 0.1)
total_delay = delay + jitter
time.sleep(total_delay)
self.connect(channels=["depth.AAPL.US", "depth.NVDA.US"])
@property
def _max_reconnect_attempts(self) -> int:
return 10
def connect(self, channels: list[str]):
"""启动 WebSocket 连接"""
ws_url = self._get_ws_url(channels)
self.ws = websocket.WebSocketApp(
ws_url,
on_open=self._on_open,
on_message=self._on_message,
on_error=self._on_error,
on_close=self._on_close
)
# run_forever 会阻塞，直到连接关闭
self.ws.run_forever(ping_interval=self.PING_INTERVAL, ping_timeout=self.PING_TIMEOUT)
def close(self):
"""主动关闭连接"""
self._running = False
if self.ws:
self.ws.close()
3.3 限频监控与告警
def start_monitoring(client: TickDBAPI):
"""启动限频监控，每分钟报告一次统计"""
import threading
import time
def monitor():
while True:
time.sleep(60)
if client._rate_limit_count > 0:
logger.warning(
f"[监控] 过去 1 分钟内触发了 {client._rate_limit_count} 次限频。"
"如果频率持续较高，请考虑："
"1. 降低查询频率"
"2. 使用 WebSocket 实时推送替代轮询"
"3. 联系 [email protected] 申请提升配额"
)
client._rate_limit_count = 0
thread = threading.Thread(target=monitor, daemon=True)
thread.start()
四、统一错误码体系的五个实际价值
回到开篇那位在凌晨两点收到告警的开发者。如果他使用的 API 采用了类似 TickDB 的统一错误码体系，事情会有什么不同？
价值一：客户端的错误处理逻辑可以预先编写并静态分发
当所有限频错误都使用同一个码（3001）时，你可以在 SDK 层面写好统一的处理策略：
def handle_error(code: int, response: dict):
if 1000 <= code < 2000:
# 认证类错误 → 检查配置
handle_auth_error(code)
elif 2000 <= code < 3000:
# 资源类错误 → 检查参数
handle_resource_error(code)
elif 3000 <= code < 4000:
# 请求合规类错误 → 判断具体类型执行对应策略
handle_compliance_error(code)
else:
# 服务端错误 → 告警 + 上报
handle_server_error(code)
这种分发逻辑是一次性编写的，后续新增错误码只需要扩展分支，不需要改变架构。
价值二：监控和告警可以基于错误码维度做统计
不同的错误码对应不同的问题根因。将错误码作为监控指标的唯一维度，运维和开发团队可以快速定位问题：
| 错误码 | 告警级别 | 处理SLA | 负责团队 |
|---|---|---|---|
| 1001/1002 | P0（立即） | 5 分钟内 | DevOps |
| 2002 | P2（常规） | 24 小时内 | 后端 |
| 3001（首次） | P2（信息） | 不需要处理 | 自动恢复 |
| 3001（连续） | P1（警告） | 30 分钟内 | 量化策略组 |
| 4XXX | P0（立即） | 立即 | SRE |
价值三：SDK 开发者可以提供精确的错误类型提示
对于使用 TickDB SDK 的开发者，好的错误码设计意味着 IDE 可以给出准确的类型提示：
# Python 类型提示示例
class TickDBError(Exception):
code: int
message: str
class RateLimitError(TickDBError):
retry_after: int # 精确到秒的等待时间
is_hard_limit: bool # 区分软限制和硬限制
# 调用方可以这样写
try:
client.get_kline("AAPL.US", "1h", 100)
except RateLimitError as e:
print(f"限频，需等待 {e.retry_after} 秒。硬限制={e.is_hard_limit}")
if e.is_hard_limit:
print("配额已耗尽，建议明天再试或联系销售")
except TickDBError as e:
print(f"其他错误 code={e.code}: {e.message}")
价值四：文档可以做到索引级精确
HTTP 429 的文档只能写"请求频率过高"，但 3001 的文档可以精确到：
- 触发条件（请求频率超过 X 次/秒）
- 全局限制还是单接口限制
- 软限制和硬限制的区分标准
- 当前配额和已消耗量
- 推荐的重试策略
这不是文档细节问题，这是"让开发者能自助解决问题"和"需要联系技术支持"之间的差距。
价值五：跨语言 SDK 的错误处理一致性
HTTP 429 在不同语言的 HTTP 客户端中表现不一致——有些库会把它当作异常抛出，有些会当作正常响应返回。开发者必须额外处理这种不一致性。
当 API 返回 {code: 3001, ...} 时，无论用 Python 的 requests、Go 的 net/http 还是 Node.js 的 axios，解析逻辑完全一致：
# Python
data = response.json()
if data["code"] == 3001:
sleep(data["retry_after"])
// Go
var resp map[string]interface{}
json.NewDecoder(r.Body).Decode(&resp)
if resp["code"] == float64(3001) {
retryAfter := int(resp["retry_after"].(float64))
time.Sleep(time.Duration(retryAfter) * time.Second)
}
// TypeScript
const resp = await response.json();
if (resp.code === 3001) {
await new Promise(resolve => setTimeout(resolve, resp.retry_after * 1000));
}
跨语言的统一性，让错误处理的单元测试和集成测试都可以独立于具体语言库的行为。
五、当前主流数据 API 的错误码对比
| 维度 | 标准 HTTP 429 | Polygon.io | Alpaca | TickDB 3001 |
|---|---|---|---|---|
| 限频错误码 | 429 | 429 | 429 | 3001 |
| 结构化错误编号 | ❌ | ❌ | ❌ | ✅ |
| Retry-After 精确秒数 | ✅（Header） | ✅（Header） | ✅（Header） | ✅（Header + Body） |
| WebSocket 限频处理 | ❌（无标准） | ❌（文档缺失） | ❌（文档缺失） | ✅（Body + reconnect） |
| 错误类型细分 | ❌ | ❌ | ❌ | ✅（3001 软限/3002 封禁） |
| 错误码扩展空间 | 无（HTTP 已固定） | 无 | 无 | 4 位码，数十个扩展位 |
| SDK 强类型支持 | 受 HTTP 库限制 | 受 HTTP 库限制 | 受 HTTP 库限制 | 完全自定义 |
从这个对比可以看到，HTTP 429 是一个下限保障——保证你不至于完全不知道发生了什么；而 TickDB 的 3001 体系是一个上限方案——让开发者在知道发生了什么之外，还知道该怎么做，以及做得更优雅。
六、下一步行动
如果你在编写 TickDB 集成代码，从今天起在所有 API 调用的外层包裹 3001 的处理分支。哪怕是一个简单的 if code == 3001: sleep(retry_after)，也能让你的策略在限频时自动恢复，而不是直接 crash。
如果你在选型阶段，不妨把"错误码体系的精确程度"列入供应商评估标准。这个细节反映的是团队对 API 可用性的重视程度，以及对开发者体验的理解深度。一个连限频错误都懒得精确设计的 API，大概率在其他边界条件的处理上同样粗糙。
如果你习惯用 AI 辅助开发，在 AI 助手中搜索安装 tickdb-market-data SKILL。实时代码生成时可以自动带上正确的错误处理逻辑，减少手写重试代码的工作量。
错误码是 API 的性格。
一个只告诉你"错了"的 API，和一个告诉你"错了、为什么错、下一步怎么做"的 API，对开发者来说是完全不同的工具。后者让凌晨两点的告警变成一个可处理的异常，而不是一次灾难。
风险提示：本文不构成任何投资建议。API 限频机制可能随服务版本更新而变化，请以 TickDB 官方文档 中的最新说明为准。市场有风险，投资需谨慎。