钉钉机器人触发频率限制后，最推荐的处理方向是采用指数退避算法进行重试，并结合消息队列缓冲突发流量。适用场景为自定义 webhook 机器人或企业内部 API 调用，最重要的风险边界是避免无限重试导致服务雪崩。
先说结论：遇到频率限制报错时，不要立即原样重发，必须增加等待时间并按阶梯式重试。
- 先确认返回错误码是否为 310000 或 HTTP 状态码 429
- 先处理重试逻辑中的等待时间递增，避免瞬间再次超限
- 再验证重试后消息送达率及日志中是否仍有限流报错
快速处理思路
代码层面无法通过单一命令解决，需调整发送逻辑。核心思路是捕获限流异常后，暂停发送并排队等待。
def send_with_retry(webhook, content, max_retry=3):
for i in range(max_retry):
resp = requests.post(webhook, json=content)
if resp.status_code == 200:
return True
if resp.json().get('errcode') == 310000: # 频率限制
wait_time = (2 ** i) # 指数退避：1s, 2s, 4s
time.sleep(wait_time)
else:
return False
return False为什么会这样
频率限制是钉钉服务端为了保护系统稳定性而设置的阈值，超过阈值会直接拒绝请求。公开资料中钉钉自定义机器人 webhook 通常限制为每分钟 20 条消息，部分企业 API 可能有不同的 QPS 限制，但处理机制一致。
当客户端发送速度超过服务端允许的阈值时，服务端会返回特定的错误码。如果不加处理地立即重试，会持续触发限流，导致消息永久丢失或账号被临时封禁。
分步处理
第一步：捕获特定错误码。在 HTTP 响应解析逻辑中，专门判断 errcode 310000 或 HTTP 429 状态码，将其与其他业务错误区分开。
第二步：实施指数退避。第一次重试等待 1 秒，第二次 2 秒，第三次 4 秒。不要使用固定等待时间，固定时间在并发场景下容易再次碰撞。
第三步：消息合并。如果业务允许，将短时间内多条告警合并为一条消息发送。例如将 5 条错误日志聚合为一个 Markdown 列表，减少发送次数。
第四步：设置重试上限。最多重试 3 到 5 次，超过上限后记录错误日志并丢弃，防止单个失败消息阻塞整个发送队列。
怎么验证是否生效
查看应用日志，搜索关键词“310000”或“frequency”。生效后的日志应显示首次失败后，后续重试成功，且没有连续密集的限流报错。
在钉钉群内观察消息接收情况，正常生效后，突发流量期间的消息会有轻微延迟，但不会大量丢失，且不会出现“机器人发送消息过于频繁”的系统提示。
常见坑
无限重试循环：代码中缺少重试次数计数器，导致程序在限流期间死循环占用 CPU 资源。
忽略全局队列：单个接口重试成功，但上游生产消息的速度远大于发送速度，导致内存中消息队列堆积溢出。
错误码混淆：将网络超时错误当作限流错误处理，导致不必要的长时间等待，影响正常消息时效性。
常见问题
钉钉机器人限流的具体错误码是多少？
自定义 webhook 机器人通常返回 errcode 310000，部分接口可能返回 HTTP 429 状态码。
消息合并会不会影响告警及时性？
会引入秒级延迟，但能显著降低触发限流的概率，适合非核心链路的告警聚合。
重试失败后消息怎么处理？
建议写入持久化存储（如数据库或磁盘文件），待服务恢复后由定时任务补偿发送。
参考来源
钉钉开放平台 - 自定义机器人接入说明