去年给一家做教育机构的公司搭客户管理系统需求挺明确销售加客户微信后客户信息自动同步到CRM里方便后续跟进。我第一版做得特糙——定时任务每隔10分钟调一次getContactList拉好友列表跟库里对比找出新增的再同步到CRM。上线第一天销售就投诉了我刚加的客户CRM里咋半天看不到10分钟的延迟销售那边感觉就是半天。更尴尬的是有个客户加了好友又删了我的定时任务正好在那两次之间跑的完全没感知到这个客户来过。销售后来跟进才发现对方早删了好友尴尬得不行。后来我才知道有个东西叫事件回调——微信那头发生任何变化Eyun会主动推给你不用你定时去拉。加上事件回调后客户加好友几秒内CRM就同步了删好友也能马上标记。这篇就把我用到的4种事件回调类型讲清楚每种什么时候触发、回调数据长啥样、能干啥用全部掰开说。一、消息接收回调这是最常用的一种。用户给你的微信号发消息时Eyun会实时把这个消息推给你。触发时机用户发了文本、图片、语音、视频任何消息类型都会触发几秒内推到你的回调地址。回调数据大概长这样wId哪个微信实例收到的、fromUser发送方的wxid、msgType消息类型text/image/voice这些、content消息内容、msgId消息唯一标识。其中msgId特别重要去重全靠它。应用场景自动回复、客服分发、意图识别。我做的客服系统就是收到消息回调后先看是不是常见问题是的话自动回不是的话转人工客服同时把消息塞进队列做意图分析。踩坑msgType一定要判断全。我早期只处理了text结果用户发个图片过来我的程序直接忽略客户以为我没收到又发了一遍。后来把图片、语音、视频、链接、名片全加上处理分支才消停。还有个坑——群里消息也会触发这个回调fromUser是发消息那个人的wxid但你要区分是私聊还是群聊得看消息里有没有groupId字段。消息接收回调的实时性是这套机制的核心价值想深入了解回调格式和字段含义可以看 Eyun开发文档 里关于消息事件的说明每种消息类型的字段都列得很全。二、好友变更回调好友添加或者删除的时候触发。这个回调解决了我开头说的那个问题——实时感知联系人变化。触发时机两种情况——有人加了你的微信好友或者有人把你删了。一加一删都会推。回调数据wId哪个实例、friendWxId对方的wxid、changeTypeadd表示新增delete表示删除。简单直接三个字段搞定。应用场景客户流失预警、联系人自动同步CRM。我现在做的系统收到add回调就把这个联系人同步到CRM打上新客户标签销售当天就能跟进收到delete回调马上标记已流失同时触发召回流程——发个关怀消息或者提醒销售电话回访。踩坑delete回调别处理得太激进。我一开始收到delete就立马发召回消息结果好几个客户反馈我没删啊怎么收到你的召回消息。排查发现是对方账号异常或者网络波动导致的误判Eyun推了delete但实际没删。后来我加了延迟确认——收到delete后等5分钟再调getContactList确认一次真没了才标记流失误判率降到接近零。三、群变更回调群成员变化或者群信息变化时触发。做社群运营的离不开这个。触发时机有人进群、有人退群、群名称改了、群公告变了这些都会推。回调数据wId哪个实例、groupId哪个群、changeType变化类型比如memberJoin/memberLeave/nameChange、memberWxId变化的成员wxid群信息变更时可能没有这个字段。应用场景社群管理、广告成员清理。我给一个客户做的社群机器人收到memberJoin回调就自动发欢迎语群规收到memberLeave回调就记一下频繁有人退的群要警惕是不是内容出问题了。还有个实用功能——监测到有人进群就发广告回调里拿到memberWxId后立刻查这个人的历史行为有广告记录的直接踢。踩坑群变更回调量大的时候别同步处理。一个大群几百号人搞活动的时候进进出出频繁回调一波接一波。你要是在回调里同步查数据库做判断5秒超时妥妥的。我的做法是回调只负责记日志返回200真正的判断和处理丢队列异步做。群管理相关的接口和回调事件Eyun平台 上有专门的章节讲建群、踢人、改群名的接口都有。四、账号状态回调这个回调是给你的微信实例本身用的——实例上线、下线、出异常的时候会推。触发时机微信扫码登录成功上线、主动退出或者异常掉线下线、网络问题或者被限制时异常。这几种状态变化都会推。回调数据wId哪个实例、statusonline表示上线offline表示下线error表示异常、有时还会带个reason字段说明原因。应用场景服务可用性监控、自动重连。我有5个微信号同时跑每个号一个wId。要是哪个号突然掉线了我得第一时间知道不然客户发消息没人回体验极差。加了状态回调后收到offline立马告警到钉钉同时触发自动重连流程。收到error就更严重了可能是被限制了得人工介入。踩坑error状态别傻等自动恢复。我有一次收到error回调以为跟平时一样网络波动等它自己重连结果等了两小时都没上线。一查是被临时限制了得手动处理。从那以后收到error我直接告警让人介入不再指望自动恢复。还有个坑——刚登录的时候online回调可能推好几次因为重连机制会重复触发记得按wId时间去重。四种回调对比放一张表对比下方便选型回调类型触发频率数据量实时性要求典型应用消息接收高每条消息都推大秒级自动回复、客服分发好友变更低加删才推小秒级客户同步、流失预警群变更中看群活跃度中秒级社群管理、广告清理账号状态极低状态变才推极小秒级可用性监控、自动重连看出来了吧消息接收量大但必须快账号状态量小但绝对不能漏。不同回调处理策略不一样我一般给四类回调各开一个队列互不影响。统一回调处理器下面是我用的统一回调处理器所有回调走一个入口根据eventType分发到不同handler。这样加新事件类型好扩展统一的地方也好加日志和限流import logging, threading class CallbackDispatcher: 统一回调分发器按事件类型路由到不同处理器 def __init__(self): self.handlers {} # eventType - [handler函数] def register(self, event_type, handler): self.handlers.setdefault(event_type, []).append(handler) def dispatch(self, event): 收到回调调这个异步分发不阻塞返回200 etype event.get(eventType) wid event.get(wId) handlers self.handlers.get(etype, []) if not handlers: logging.warning(f未注册的事件类型: {etype}, wId{wid}) return for h in handlers: # 异步执行单个handler挂了不影响其他 threading.Thread(targetself._safe_run, args(h, event), daemonTrue).start() def _safe_run(self, handler, event): try: handler(event) except Exception as e: logging.error(f处理器异常: {handler.__name__}, event{event}, err{e}) # 注册各类回调 dispatcher CallbackDispatcher() def on_message(event): # 消息接收自动回复 or 转客服 msg_type event.get(msgType) if msg_type text and 退款 in event.get(content, ): route_to_human(event) # 转人工 else: auto_reply(event) def on_friend_change(event): # 好友变更同步CRM if event.get(changeType) add: sync_contact_to_crm(event.get(friendWxId)) elif event.get(changeType) delete: schedule_loss_check(event.get(friendWxId)) # 延迟确认流失 def on_account_status(event): # 账号状态告警重连 status event.get(status) if status in (offline, error): alert_ops(event.get(wId), status) if status offline: trigger_reconnect(event.get(wId)) dispatcher.register(message, on_message) dispatcher.register(friend, on_friend_change) dispatcher.register(account, on_account_status)这段代码的核心是统一入口异步分发异常隔离。所有回调从dispatch这一个口子进来按eventType分发每个handler异步跑互不阻塞一个handler报错不会拖垮其他的。我用了大半年加新事件类型就是register一下不用动分发逻辑维护起来特省心。总结做完客户管理系统那个项目我才真正理解事件回调的价值——它让你的系统从主动去问变成被动接收效率和实时性完全不在一个量级。以前定时拉好友列表那套做法现在想想就是蠢。四类回调各有各的用处但有几个通用的原则得记住回调里别干耗时操作、5秒内必须返回200、按msgId或eventId做幂等、不同类型回调分开队列。这几点做到了回调这块基本不会出大问题。如果你刚开始接触微信的事件回调建议先把 Eyun开发文档 里回调那一章通读一遍把每种回调的触发条件和数据结构摸清楚再动手写代码。想清楚再写比边写边改效率高得多这事我交过不少学费才学乖的。
