如何批量发送钉钉机器人消息避免触发频率限制报错？

批量发送钉钉机器人消息避免频率限制报错，最推荐的做法是在客户端实现消息队列或增加发送间隔，适用场景是自定义 Webhook 机器人，风险边界是强行高频请求会导致机器人被临时禁用或 IP 被封禁。

先说结论：必须遵守钉钉开放平台对自定义机器人的频率限制，通过代码控制发送节奏或升级为企业内部应用来解决。

快速处理思路

如果无法立即改造架构，可在发送循环中增加强制休眠时间。例如每分钟限制 20 条消息，则每条消息发送后休眠 3 秒以上。代码逻辑应在 HTTP 请求完成后执行 sleep 操作，而不是请求前。

钉钉网关对每个 Webhook 地址设有独立的访问频率保护机制。当单位时间内请求次数超过阈值，服务器会直接拒绝请求并返回错误码，这是为了防止单一机器人滥用接口影响平台稳定性。自定义机器人设计初衷是通知而非批量营销，因此限制较严格。

第一步，确认当前机器人类型和限制。自定义 Webhook 机器人通常限制为每分钟 20 条消息，企业内部应用回调通知限制不同。查阅钉钉开放平台文档确认最新数值。

第二步，改造发送代码增加节流控制。在循环发送消息时，记录上一次发送时间戳，若当前时间与上次时间间隔小于安全阈值（如 3 秒），则暂停当前线程等待。

第三步，引入消息队列缓冲突发流量。使用 Redis 或本地队列暂存待发送消息，由独立消费者按固定速率从队列取出并调用钉钉接口，避免业务高峰直接冲击接口。

第四步，评估升级为企业内部应用。若业务确实需要高频通知，应创建企业内部应用使用服务端 API，其频率限制远高于自定义机器人，且支持更多消息类型。

查看应用程序日志，确认不再出现 HTTP 状态码 429 或钉钉返回的错误码 310000（频率限制）。观察消息送达情况，确认接收端收到的消息时间间隔符合预期节流设置，且无丢失现象。

不要在捕获频率限制错误后才进行重试，这会导致错误已经发生且可能加重封禁风险。不要多个服务实例共用同一个 Webhook 地址而不做分布式限流，这会叠加请求次数导致更快触发限制。不要忽略钉钉返回的 retry-after 头部信息，若有应优先遵循。

公开资料显示通常为每分钟 20 条，但具体数值以钉钉开放平台最新文档为准，不同时期或不同账号类型可能存在差异。

通常不会永久禁用，但会暂时无法发送消息，频繁触发可能导致 Webhook 地址被长期封禁，需要重新生成地址。

企业内部应用通过服务端 API 发送，频率限制更高且支持并发，自定义机器人通过 Webhook 发送，限制较低且适合简单通知。