在 Node.js 里封装钉钉机器人请求时，最稳妥的做法是基于 axios 配合重试中间件，并严格遵循钉钉官方的频率限制。
先说结论：不要自己写 setTimeout 循环，直接用成熟的重试库配合 HTTP 客户端，同时必须处理 429 状态码。
- 适合：Node.js 后端服务、定时任务通知、异常告警场景
- 先看：axios-retry 或 p-retry 库的文档说明
- 建议：采用指数退避策略，避免瞬间加重服务器负担
快速处理思路
不需要复杂的封装，核心是拦截 HTTP 响应并判断是否需要重发。下面是一个基于 axios 的最小化实现思路：
const axios = require('axios');
const axiosRetry = require('axios-retry');
axiosRetry(axios, {
retries: 3,
retryCondition: (error) => {
return axiosRetry.isNetworkOrIdempotentRequestError(error) || error.response?.status === 429;
},
retryDelay: axiosRetry.exponentialDelay
});为什么会这样
网络请求失败通常分为两类：一是网络波动导致的连接超时或断开，二是服务端暂时不可用。钉钉机器人接口在高并发或触发频率限制时，会返回特定错误码。如果不做重试，一次抖动就会导致告警丢失；但如果盲目重试，又可能触发频率限制被封禁。
分步处理
1. 安装依赖：在项目目录执行 npm install axios axios-retry。
2. 配置重试策略：重点配置 retryCondition，除了网络错误，务必包含 429 (Too Many Requests) 和 5xx 服务端错误。
3. 设置退避时间：不要固定间隔，使用指数退避（如 1s, 2s, 4s），给服务端恢复时间。
4. 封装发送函数：将钉钉 webhook 地址和消息内容封装成独立函数，便于统一调用和测试。
怎么验证是否生效
1. 日志检查：在重试回调中打印日志，确认 retryCount 是否递增。
2. 模拟失败：本地搭建一个返回 500 或 429 的 mock 服务，替换钉钉 webhook 地址进行测试。
3. 观察行为：确认在连续失败达到设定次数后，程序不再重试并抛出最终错误。
常见坑
1. 频率限制陷阱：钉钉自定义机器人有严格的频率限制，重试时需累加等待时间，避免短时间内发送过多请求。
2. 无限重试风险：如果没有设置最大重试次数，网络永久故障会导致程序卡死或资源耗尽。
3. 阻塞事件循环：避免在重试逻辑中使用同步等待，必须使用异步 setTimeout 或 Promise 延迟。
参考来源
- 钉钉开放平台 - 自定义机器人接入 (https://open.dingtalk.com/document/robots/custom-robot-access)
- axios-retry - GitHub 仓库文档 (https://github.com/softonic/axios-retry)