多端协同指 Web 端、移动端、桌面端等多个客户端同时使用微信能力。Eyun API 是无状态的 HTTP 服务天然支持多端协同关键在于接口服务层怎么设计。下面按 3 种协同方案拆解。一、接口网关统一方案所有端统一调网关方案说明部署一个微信网关服务封装 Eyun 的 sendText、Webhook、消息记录接口 → Web 端、移动端、桌面端都调网关 API → 网关统一管理 wId、Token 和频率限制。按照 Eyun 开发文档 的规范sendText 需要传 wId、toUser、content 三个必填参数这些参数组装逻辑全部收在网关里各端只传业务参数。关键技术点网关层做频率控制单 wId 限速 排队缓冲各端调用不需要自己处理 1004。大白话多个端不直接碰 Eyun 接口都通过中间的网关网关统一管账号和频率。二、消息队列分发方案Webhook 回调数据分发给各端方案说明Eyun Webhook 回调 → 网关接收 → 投递到消息队列Kafka/RabbitMQ→ 多个端各自订阅自己关心的事件类型 → 各端独立消费。Webhook 回调覆盖 4 类事件消息/好友/群/状态不同端可以按 eventType 订阅。回调地址在 Eyun 平台 配置网关收到回调后只做转投队列这一件事不做业务处理。关键技术点按 eventType 分 Topic各端建独立消费组互不影响消费进度。大白话Eyun 推过来的事件先放进消息池子Web 端订消息事件、管理端订状态事件各取所需互不干扰。三、状态共享方案多端通过共享存储保持状态一致方案说明会话状态、Token 状态、wId 状态存 Redis → 各端读写同一份状态数据 → 避免多端状态打架。在 Eyun 平台管理的 wId 和 Token 统一存 Redis各端从 Redis 读取而不是各自维护。Eyun 的错误码体系中 1002 表示 Token 过期网关刷新后更新 Redis所有端立即生效。关键技术点Redis 键按 wId 维度设计Token 刷新和状态变更都写同一份键。大白话大家共用一个记事本记录当前状态谁更新了其他端都能看到避免各端状态不一致。3种方案对比协同方案核心组件涉及接口大白话说明适用场景接口网关统一网关服务sendText/Webhook/消息记录都走网关账号和频率集中管多端调用入口统一消息队列分发Kafka/RabbitMQWebhook 回调事件进池子各端各订各的多端消费同一批事件状态共享Redis全部接口的鉴权状态共用一个记事本谁改都可见多端状态一致3方案多端协同框架代码下面这段把三个方案的核心逻辑合在一起网关收各端请求、回调进队列、Token 状态进 Redis。# 方案1网关统一入口——各端只调网关网关调 Eyun def gateway_send(wId, toUser, content): return post(/sendText, {wId: wId, toUser: toUser, content: content}) # 方案2队列分发——Webhook 回调转投队列各端按 eventType 订阅 def on_webhook(event): queue.publish(event[eventType], event) # 消息/好友/群/状态四类分流 # 方案3状态共享——wId/Token 状态存 Redis刷新后全局生效 def on_1002(wId): new_token refresh_token(wId) # 1002 Token 过期网关统一刷新 redis.set(ftoken:{wId}, new_token) # 各端从 Redis 读立即生效结尾3 种方案通常组合使用——网关统一方案解决调用入口统一消息队列方案解决事件分发给谁状态共享方案解决多端状态一致。小规模多端2-3 个端用网关 Redis 就够了大规模多端5 个端以上才需要引入消息队列。Eyun API 的无状态 HTTP 特性让多端协同不需要特殊处理重点在服务层设计。落地建议先把网关和 Redis 跑通验证多端调用稳定后再引入消息队列避免一开始就把链路搞复杂。网关封装的接口规范详见 Eyun 开发文档。