1. 引言
一到整点，催办、日报、群通知一起打出去，通道开始排队，值班说接口不稳。不稳常常是把一天的量挤进同一秒，再在失败时无上限重试。频率限制是保护层。优化是把峰值摊开，而不是把重试叠成雪崩。
2. 先限速，再谈快
同一会话连续字、图、文件要过频率。同一订单同一状态只成功一次。失败重试必须有上限和间隔。点窗口失败去补 HTTP，或 HTTP 超时去补点击，都会双写。
QiWe API 只负责投递，限速和削峰在你的任务表。
python
def dispatch(job, limiter, send):
if not limiter.allow(job.device, job.to):
return "later"
return send(job.device, job.to, job.text)具体限额和并发建议，对照 API文档 再定，不要抄一份过期数字写进代码。
3. 性能优化落在队列
回调入口尽快返回。模型、附件、批量通知全部在消费者。消费者按设备分片，避免一个号被所有任务围殴。积压恢复时禁止按昨天时间戳全量原文重放。
出站走 QiWe API。优化手段是：分片、令牌桶、业务键、错过窗口丢弃而不是补发问候。
| 反模式 | 结果 | 改法 |
|---|---|---|
| 定时任务直接发送 | 错过无法收、无法限 | 只扫描任务表 |
| 失败立刻重试 | 雪崩 | 间隔 + 上限 |
| 全员同一秒 | 像群发骚扰 | 抖动打散 |
| 回调里调模型 | 超时连发 | 入口入队 |
附件和批量不要和文字挤在同一秒。
4. 验收
把并发加大，目标会话不应出现重复业务通知；入口超时重推仍一条；过了最晚窗口的早安不得补发。
5. 总结
企业微信API的性能问题，优先查任务调度，再查通道。限速是功能，不是故障。把峰值摊开，比把超时调长更有效。