实际做消息触达时，运营同学的需求往往是“同一条入口，根据场景发文本、图片或文件”。如果能用一套调度逻辑覆盖多种消息类型，代码维护成本会低很多。下面以 Eyun 的 RESTful 接口为例，梳理如何用一套代码控制不同类型消息的发送。
一、类型判断
入口处先识别要发什么类型的消息，这一步决定了后续走哪条分支。通常用一个枚举字段（比如 type=text/image/file）来标记，由业务侧传入或从模板配置读取。提前判断的好处是能把校验逻辑收口在一处，避免后面每个接口都重复判断参数完整性。
二、接口路由
Eyun 针对不同消息类型提供了 sendText、sendImage、sendFile 等独立接口，路由层根据类型字段映射到对应 URL。路由表可以用字典或配置维护，新增类型时只要加一条映射即可扩展，不用改主流程。所有接口统一走 JSON 格式请求、Token 鉴权，协议层是稳定的。
三、参数组装
不同接口的请求体字段有差异，文本要 content，图片要文件路径或 url，文件还要带文件名。组装层按接口签名拼装 payload，公共字段（wId、目标 ID）统一注入，私有字段按类型补齐。这一步要做好必填校验，缺字段会直接返回 1004，影响触达成功率。
四、结果处理
请求返回后统一解析 errcode，1000 成功，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, json=payload, headers=headers) return resp.json().get("errcode") == 1000把类型判断、路由、组装、处理拆开后，新增一种消息类型只要动路由表和组装规则，主链路基本不动。这套结构在多业务线复用同一个发送通道时，维护起来比硬编码 if-else 清爽很多。
