消息撤回接口解决的是发错了能补救的问题。但撤回有严格的时效限制理解限制才能用对场景。一、撤回的基本机制撤回接口通常需要两个参数接收方toUser好友 wxid 或群 ID和要撤回的消息标识原消息发送成功后接口返回的 msgId。也就是说撤回依赖发送时保存的 msgId——没存 msgId 就撤不回。撤回成功后对方客户端显示对方撤回了一条消息消息内容不可见。二、时效限制——撤回不是随时可以微信客户端的撤回有时效窗口通常为两分钟具体以接口文档为准超过时效接口返回失败。程序里不要设计过了一小时再撤回的逻辑必然失败。这意味着撤回能力只适用于刚发出去就发现错了的场景。发送时间和撤回请求时间的间隔必须在窗口内。三、典型使用场景内容错误自动回复系统发了错误内容知识库匹配错、变量填充错监控发现后立即撤回重发。发错对象消息路由 bug 导致发到错误的群或人紧急撤回。重复发送重试机制产生重复消息撤回多余的那条。这些场景的共同点是秒级发现、秒级撤回。四、撤回后的处理撤回不是终点。撤回后通常要补发正确内容并在日志里记录原消息内容是什么、为什么撤回、补发了什么。这条审计链在客服场景里尤其重要。撤回能力对照要素说明必要参数toUser 原消息 msgId时效窗口发送后短时间内以文档为准超时效结果接口返回失败对方感知显示撤回了一条消息前提条件发送时保存了 msgId撤回与补发实现def send_with_recall(to_user, content): 发送消息并保存msgId支持撤回 r api(sendText, {wId: WID, toUser: to_user, content: content}) if r.get(code) 1000: msg_id r[data][msgId] db.save(sent_messages, { msgId: msg_id, toUser: to_user, content: content, sent_at: now() }) return msg_id return None def recall_and_resend(msg_id, to_user, new_content): 撤回错误消息并补发 original db.query(sent_messages, msgIdmsg_id) if not original: return False, 找不到原消息记录 elapsed seconds_since(original[sent_at]) if elapsed RECALL_WINDOW: # 超过撤回窗口 return False, f已超时效{elapsed}秒无法撤回 r api(revokeMessage, {wId: WID, toUser: to_user, msgId: msg_id}) if r.get(code) ! 1000: return False, f撤回失败{r.get(code)} # 记录审计日志 db.save(recall_log, { msgId: msg_id, old_content: original[content], new_content: new_content, time: now() }) # 补发 if new_content: send_with_recall(to_user, new_content) return True, 撤回并补发成功落地建议用撤回功能的两个前提发送消息时必须落库 msgId否则无消息可撤业务系统要有快速发现错误内容的机制关键词审计或人工反馈通道。撤回窗口很短整个发现-撤回-补发链路要在两分钟内走完。接口参数和时效说明以 Eyun 开发文档 为准。