实际做消息触达时运营同学的需求往往是“同一条入口根据场景发文本、图片或文件”。如果能用一套调度逻辑覆盖多种消息类型代码维护成本会低很多。下面以 Eyun 的 RESTful 接口为例梳理如何用一套代码控制不同类型消息的发送。一、类型判断入口处先识别要发什么类型的消息这一步决定了后续走哪条分支。通常用一个枚举字段比如 typetext/image/file来标记由业务侧传入或从模板配置读取。提前判断的好处是能把校验逻辑收口在一处避免后面每个接口都重复判断参数完整性。二、接口路由Eyun 针对不同消息类型提供了 sendText、sendImage、sendFile 等独立接口路由层根据类型字段映射到对应 URL。路由表可以用字典或配置维护新增类型时只要加一条映射即可扩展不用改主流程。所有接口统一走 JSON 格式请求、Token 鉴权协议层是稳定的。三、参数组装不同接口的请求体字段有差异文本要 content图片要文件路径或 url文件还要带文件名。组装层按接口签名拼装 payload公共字段wId、目标 ID统一注入私有字段按类型补齐。这一步要做好必填校验缺字段会直接返回 1004影响触达成功率。四、结果处理请求返回后统一解析 errcode1000 成功1001 鉴权失败1002 通常对应目标不可达要做相应重试或丢弃。建议把错误码和消息类型一起打日志方便后续按类型统计失败率、定位是哪类消息出问题。结合 Webhook 的 4 类事件回调还能在消息真正送达后做二次状态更新闭环更完整。五、环节对比环节做什么核心逻辑注意点类型判断识别消息类型枚举字段 type校验收口在一处接口路由映射到对应 URL字典维护路由表新增类型易扩展参数组装拼装请求体公共字段统一注入缺字段返回 1004结果处理解析错误码1000 成功、1001/1002按类型统计失败率六、调度示例下面是用一套调度逻辑发不同类型消息的伪代码路由表和参数组装都集中在一处import requests ROUTE {text: /sendText, image: /sendImage, file: /sendFile} def send(wid, token, mtype, target, body): url https://api.eyunz.com ROUTE[mtype] headers {Token: token} payload {wId: wid, toWxid: target, **body} resp requests.post(url, jsonpayload, headersheaders) return resp.json().get(errcode) 1000把类型判断、路由、组装、处理拆开后新增一种消息类型只要动路由表和组装规则主链路基本不动。这套结构在多业务线复用同一个发送通道时维护起来比硬编码 if-else 清爽很多。