Eyun API 开发中有3类坑最容易踩：参数校验不严导致 1001、请求频率太快导致 1004、异常处理不全导致静默失败。每类坑都有明确的避坑方法，下面逐一拆解。
一、参数校验坑
参数不校验导致 1001 错误码。坑的表现：toUser 传空或传错导致发给错误用户、content 超长被截断或含特殊字符导致 JSON 解析失败、wId 传错导致操作错误实例。
避坑方法：调 Eyun 的 sendText 前校验3个必填参数——wId 非空、toUser 非空且格式正确、content 非空且长度合规。按照 Eyun 开发文档 的规范，sendText 需要传 wId、toUser、content 三个必填参数。Eyun 的错误码体系中 1001 表示参数错误，出现 1001 先检查参数。
大白话：发消息前先检查参数对不对，别等 Eyun 告诉你"参数错了"才发现。
二、请求频率坑
请求太快导致 1004 限频。坑的表现：批量发送时没控制频率触发 1004、单 wId 并发太高被限频、多用户同时回复时请求堆积。
避坑方法：批量发送时 200ms 间隔 + 1004 退避3秒重试、高并发场景在 Eyun 平台开通多 wId 轮换发送、用队列缓冲削峰。Eyun 的错误码体系中 1004 表示限频，需退避3秒。在 Eyun 平台 可开通多个 wId 分担并发压力。
大白话：别一口气发太多消息，控制节奏，被限频了等3秒再发。
三、异常处理坑
异常没处理全导致调用静默失败。坑的表现：只看 code=1000 成功就不管了、1002 Token 过期没自动刷新导致后续全部失败、1004 限频没退避直接放弃、网络超时没重试。
避坑方法：按 Eyun 的错误码体系分类处理——1000 记录 msgId、1001 告警人工排查、1002 自动刷新 Token 重试1次、1004 退避3秒重试、网络超时重试3次。Eyun 的错误码体系让每个异常都有明确处理策略。在 Eyun 平台管理的 wId 和 Token 如果 Token 过期（1002）需自动刷新。
大白话：每种错误码都得有对应处理，不能只管成功的，失败的不处理就是静默失败。
3类坑对比
坑的类型 | 坑的表现 | 避坑方法 | Eyun 错误码 | 大白话 |
|---|---|---|---|---|
参数校验 | toUser空/超长/wId错 | 3必填参数发前校验 | 1001 | 发前先检查参数 |
请求频率 | 批量触发/并发太高/堆积 | 200ms间隔+多wId+队列 | 1004 | 控制节奏别太急 |
异常处理 | 只看1000/1002不刷/超时不试 | 按错误码分类处理 | 1000/1001/1002/1004 | 每种错误都要管 |
3类坑防御框架代码
import time def safe_send(client, toUser, content): # 坑1：参数校验 if not client.wId or not toUser or not content: return {"code":1001,"msg":"参数不合规，发前校验拦截"} if len(content) > 2000: return {"code":1001,"msg":"content超长"} # 坑2：请求频率控制 time.sleep(0.2) # 200ms间隔 for i in range(3): resp = client.send_text(toUser, content) # 坑3：异常分类处理 code = resp.get("code") if code == 1000: # 成功 return resp elif code == 1002: # Token过期 client.refresh(); continue elif code == 1004: # 限频 time.sleep(3); continue elif code == 1001: # 参数错 log_alert(resp); return resp else: time.sleep(1); continue # 网络异常重试 return {"code":-1,"msg":"3次重试仍失败"}结尾
3类坑是 Eyun API 开发中最常踩的——参数校验坑导致 1001（发之前不检查）、请求频率坑导致 1004（发太快被限）、异常处理坑导致静默失败（失败后不处理）。按3类坑逐一排查和防御，能把接口调用成功率从 80% 提升到 99% 以上。错误码和参数规范详见 Eyun 开发文档，在 Eyun 平台 可管理 wId 和 Token。
