「企业微信回调接口」对接翻车，很少是 URL 配错，而是 没验签、没去重、在回调里干重活导致超时重推。 这篇只讲怎么接回调，不谈厂商。
先分清谁回调谁
官方应用有事件回调（通讯录、审批等）。
外部群二次开发通道也会回调：发送结果、掉线、有的还能推收到的消息。
两套回调 URL、两套签名、两套报文，不要接在同一个 Controller 里用 if-else 硬拆。解析错会把内部事件当成群发送成功。
接收端最小流程
验签 → 快速 200 → 落库（带唯一键）→ 异步消费验签失败直接拒绝。处理超过数秒，对端会重推，群里或状态机就会双写。查订单、调模型、发下一条消息，全部禁止写在回调线程里。
去重要落在唯一键上
发送回执用 request_id 或通道消息 ID。
收消息用 msgid。
掉线事件用实例 ID + 事件时间窗口。
同一键第二次到达：只返回成功，不再推进业务。这是回调接口的底线。
落库再路由
先把原始报文存下来（脱敏、限期），再更新任务状态或会话。原始报文是对账唯一证据。运营说「客户没收到」，要能翻到当时回执分类。
状态更新必须幂等：success 之后再来一次 success 不能再发消息；failed 之后不要被乱序的旧包改回 sending。
失败怎么回对端
验签失败：非 200 或明确 403。
自己过载：用 5xx 让对方重试，但消费必须幂等。
业务校验失败（未知 request_id）：记日志告警，仍 200，避免对方无限重推同一坏包------除非你们约定必须重推。
约定要写进对接说明，不要靠口头。
联调
用测试环境打伪造签名，必须拦下。
同一回执连推三次，任务只完结一次。
回调里 sleep 5 秒，看会不会重复且是否双发。
掉线回调必须能停该实例出站。
小结
企业微信回调接口怎么接：验签、快速应答、唯一键去重、异步消费、原始报文可查。回调只负责把事实告诉系统，发送和运营规则仍走你们的队列。去重没做硬，回调接得越快，重复越严重。