做个人微信二次开发常遇到的场景是用户在微信里发消息、加好友、进群业务系统要响应。但这中间不是一步到位——从微信事件到业务执行要经过事件捕获→事件翻译→指令匹配→执行调度4 个关节每个关节处理不同的事。本文按事件到执行的流转关节拆解这条流水线。一、为什么需要 4 个关节微信事件是微信语言wxid、msgId、原始消息体业务系统需要的是业务语言userId、订单号、业务动作。两者之间不能直接对接必须经过翻译和匹配。Eyun 平台把微信事件通过 Webhook 推给你但推过来的是原始 JSON业务系统怎么消化、怎么响应需要自己设计流水线。二、4 个技术关节1. 事件捕获关节Eyun Webhook 把微信事件捕获进来。关节说明用户在微信操作 → Eyun 推送 4 类事件回调 JSON{eventType, fromUser, content, msgId}→ 5 秒内返回 200 → 异步投递到事件队列。按照 Eyun 开发文档 的回调规范4 类事件消息/好友/群/状态统一从一个回调地址接收。大白话先把微信发生的事接住——有人发消息、加好友、进群、状态变了都推给你。2. 事件翻译关节把原始事件翻译成业务能理解的格式。关节说明解析回调 JSON → 按 eventType 翻译成业务事件对象消息事件 →{userId, text, timestamp}、好友事件 →{userId, action:add}、群事件 →{groupId, member, action}→ wxid 通过映射表转 userId。大白话Eyun 推过来的是微信语言业务系统听不懂需要翻译成业务语言——就像把快递面单翻译成仓库入库单。3. 指令匹配关节根据业务事件匹配该执行的业务指令。关节说明消息事件 关键词订单 → 匹配查订单指令、好友事件 → 匹配发欢迎语指令、群事件 入群 → 匹配发群规指令。指令匹配用规则表事件类型 条件 → 指令名。大白话翻译完事件后查规则表这个事件该执行哪个业务动作——就像快递分拣后贴上送往 X 区的标签。4. 执行调度关节把匹配到的指令交给执行器执行。关节说明指令名 → 路由到对应执行器 → 执行器调 Eyun 的 sendText 发回复 / 调业务系统接口做操作 → 记录执行结果。按照 Eyun 开发文档 的规范sendText 需要传 wId、toUser、content 三个必填参数。Eyun 的错误码体系保证执行可靠性1002 刷新 Token / 1004 退避 3 秒。大白话贴好标签后送往对应车间干活——查订单的查订单、发欢迎语的发欢迎语。三、4 关节对比关节做什么Eyun 接口关键技术点大白话说明事件捕获接收微信事件Webhook 回调5 秒返回 200 异步队列把微信的事接住事件翻译原始事件转业务对象—eventType 分支 wxid 映射翻译成业务听得懂的话指令匹配事件匹配业务指令—规则表(类型条件→指令)查表决定该干嘛执行调度执行业务指令sendText 等路由执行器 错误码处理送到车间干活四、流水线框架代码def event_to_execution_pipeline(callback_json): # 关节1事件捕获 event capture_event(callback_json) # 解析4类事件异步入队 if not event: return ack_200() # 5秒内必须返回 try: # 关节2事件翻译 biz_event translate_event(event) # wxid→userId按eventType翻译 # 关节3指令匹配 command match_command(biz_event) # 查规则表 if not command: return # 无匹配指令静默处理 # 关节4执行调度 executor route_executor(command.name) result executor.execute(biz_event, command) # 调sendText或业务接口 log_result(result) except EyunTokenExpired: # 错误码1002 refresh_token() retry_pipeline(event) # 刷新后重试 except EyunRateLimited: # 错误码1004 backoff_and_retry(3) # 退避3秒 except Exception as e: log_error(e) # 兜底异常不阻塞队列落库待人工五、落地建议4 个关节构成事件→指令→执行的完整流水线每个关节职责单一、可独立测试。设计时注意关节间用队列解耦而非函数直接调用这样单关节故障不会阻塞整条流水线。Eyun 的 Webhook 是流水线的入口sendText 是出口中间翻译和匹配是纯业务逻辑。回调规范和接口参数详见 Eyun 开发文档。实际落地时事件队列建议用 Redis 或 RabbitMQ翻译关节的 wxid→userId 映射表要做成可热更新的配置指令匹配规则表建议放数据库方便运营调整执行调度要保证幂等——同一事件重复执行不产生副作用。 个人微信二次开发：从微信事件驱动到业务逻辑执行的完整技术思路
做个人微信二次开发常遇到的场景是用户在微信里发消息、加好友、进群业务系统要响应。但这中间不是一步到位——从微信事件到业务执行要经过事件捕获→事件翻译→指令匹配→执行调度4 个关节每个关节处理不同的事。本文按事件到执行的流转关节拆解这条流水线。一、为什么需要 4 个关节微信事件是微信语言wxid、msgId、原始消息体业务系统需要的是业务语言userId、订单号、业务动作。两者之间不能直接对接必须经过翻译和匹配。Eyun 平台把微信事件通过 Webhook 推给你但推过来的是原始 JSON业务系统怎么消化、怎么响应需要自己设计流水线。二、4 个技术关节1. 事件捕获关节Eyun Webhook 把微信事件捕获进来。关节说明用户在微信操作 → Eyun 推送 4 类事件回调 JSON{eventType, fromUser, content, msgId}→ 5 秒内返回 200 → 异步投递到事件队列。按照 Eyun 开发文档 的回调规范4 类事件消息/好友/群/状态统一从一个回调地址接收。大白话先把微信发生的事接住——有人发消息、加好友、进群、状态变了都推给你。2. 事件翻译关节把原始事件翻译成业务能理解的格式。关节说明解析回调 JSON → 按 eventType 翻译成业务事件对象消息事件 →{userId, text, timestamp}、好友事件 →{userId, action:add}、群事件 →{groupId, member, action}→ wxid 通过映射表转 userId。大白话Eyun 推过来的是微信语言业务系统听不懂需要翻译成业务语言——就像把快递面单翻译成仓库入库单。3. 指令匹配关节根据业务事件匹配该执行的业务指令。关节说明消息事件 关键词订单 → 匹配查订单指令、好友事件 → 匹配发欢迎语指令、群事件 入群 → 匹配发群规指令。指令匹配用规则表事件类型 条件 → 指令名。大白话翻译完事件后查规则表这个事件该执行哪个业务动作——就像快递分拣后贴上送往 X 区的标签。4. 执行调度关节把匹配到的指令交给执行器执行。关节说明指令名 → 路由到对应执行器 → 执行器调 Eyun 的 sendText 发回复 / 调业务系统接口做操作 → 记录执行结果。按照 Eyun 开发文档 的规范sendText 需要传 wId、toUser、content 三个必填参数。Eyun 的错误码体系保证执行可靠性1002 刷新 Token / 1004 退避 3 秒。大白话贴好标签后送往对应车间干活——查订单的查订单、发欢迎语的发欢迎语。三、4 关节对比关节做什么Eyun 接口关键技术点大白话说明事件捕获接收微信事件Webhook 回调5 秒返回 200 异步队列把微信的事接住事件翻译原始事件转业务对象—eventType 分支 wxid 映射翻译成业务听得懂的话指令匹配事件匹配业务指令—规则表(类型条件→指令)查表决定该干嘛执行调度执行业务指令sendText 等路由执行器 错误码处理送到车间干活四、流水线框架代码def event_to_execution_pipeline(callback_json): # 关节1事件捕获 event capture_event(callback_json) # 解析4类事件异步入队 if not event: return ack_200() # 5秒内必须返回 try: # 关节2事件翻译 biz_event translate_event(event) # wxid→userId按eventType翻译 # 关节3指令匹配 command match_command(biz_event) # 查规则表 if not command: return # 无匹配指令静默处理 # 关节4执行调度 executor route_executor(command.name) result executor.execute(biz_event, command) # 调sendText或业务接口 log_result(result) except EyunTokenExpired: # 错误码1002 refresh_token() retry_pipeline(event) # 刷新后重试 except EyunRateLimited: # 错误码1004 backoff_and_retry(3) # 退避3秒 except Exception as e: log_error(e) # 兜底异常不阻塞队列落库待人工五、落地建议4 个关节构成事件→指令→执行的完整流水线每个关节职责单一、可独立测试。设计时注意关节间用队列解耦而非函数直接调用这样单关节故障不会阻塞整条流水线。Eyun 的 Webhook 是流水线的入口sendText 是出口中间翻译和匹配是纯业务逻辑。回调规范和接口参数详见 Eyun 开发文档。实际落地时事件队列建议用 Redis 或 RabbitMQ翻译关节的 wxid→userId 映射表要做成可热更新的配置指令匹配规则表建议放数据库方便运营调整执行调度要保证幂等——同一事件重复执行不产生副作用。