高并发时段偶发丢消息，官方建议加幂等和重试。我把回调改造的代码贴出来，求更优解……
给客户做的 Coze 智能体发布到飞书机器人，平时没事，一到上午 10 点消息高峰就偶发丢消息：用户发了，机器人不回，后台也没日志。
排查结论：飞书回调有超时要求（3 秒），Coze 生成长答案超时就丢。官方建议是回调先 ack 再异步处理。我现在的改造：回调收到消息立即返回成功，把消息丢进队列，处理完再主动调飞书接口发答案；加了幂等键（消息 ID）防止重试重复发。改完两周没再丢过。
改造代码贴在正文附件。总觉得这个「队列 + 主动推送」的方案有点重，有更轻的解法吗？
方案不重，这是标准做法。再补一刀：队列加个死信告警，处理失败的消息推到你的飞书，不然客户比你先发现故障。
回复 @自动化小王：死信告警已加上，就一行 webhook。果然这种坑你也踩过。
更轻的解法：Coze 开流式输出，首 token 出来就先 ack 一部分？不过飞书卡片消息更新有频率限制，体验一般，还是你的队列稳。
幂等键用消息 ID + 用户 ID 拼一下更稳，飞书的消息 ID 在转发场景会重复。
码住代码。同款问题我在企微也遇到了，回调超时这病是平台通有病。
看不太懂代码，但看懂了「客户比你的监控先发现故障是最尴尬的」，这就去把告警加上。
评论（6）
方案不重，这是标准做法。再补一刀：队列加个死信告警，处理失败的消息推到你的飞书，不然客户比你先发现故障。
回复 @自动化小王：死信告警已加上，就一行 webhook。果然这种坑你也踩过。
更轻的解法：Coze 开流式输出，首 token 出来就先 ack 一部分？不过飞书卡片消息更新有频率限制，体验一般，还是你的队列稳。
幂等键用消息 ID + 用户 ID 拼一下更稳，飞书的消息 ID 在转发场景会重复。
码住代码。同款问题我在企微也遇到了，回调超时这病是平台通有病。
看不太懂代码，但看懂了「客户比你的监控先发现故障是最尴尬的」，这就去把告警加上。