错误处理

先判断 HTTP 状态，再判断响应体中的 code：

场景	处理建议
401 / 403，或 Token 相关消息	停止当前访客请求，向业务服务端刷新访客 Token 后重新进入 /visitor。
code: -1（客服端）	客服登录态失效，跳转登录页。
code: 1 / 2	参数缺失、业务校验失败或无权限，展示 msg 并不要盲目重试。
429 或“频率过快”	退避后重试，避免并发重复发送。
5xx 或推送失败	保留本地待发送状态，重新拉取消息历史确认是否已落库。

消息发送应使用 tmp_mid 做幂等展示：先显示本地待发送消息，收到相同 tmp_mid 的回执或实时事件后替换为服务端 mid。

统一处理顺序

收到响应
  ↓
HTTP 是否为 2xx？──否──→ 处理网络/鉴权/服务端错误
  ↓ 是
响应是否为 JSON 且 code 为 0？──否──→ 展示 msg，按业务码决定是否重试
  ↓ 是
更新本地状态，等待或合并实时事件

多数业务校验失败仍使用 HTTP 200，因此不能只判断 fetch 或 XHR 的成功回调。

常见响应形态

普通接口使用：

{
  "code": 1,
  "msg": "错误说明",
  "data": []
}

访客 Token 缺失、无效或过期时，服务端会返回对应 HTTP 状态和同样的 JSON 信封。客服接口在未登录时通常返回：

{ "code": -1, "msg": "请登录", "data": [] }

重试策略

场景	是否自动重试	正确处理
网络短暂断开、Socket 重连	可以	使用退避；恢复后重新订阅并补拉历史。
消息发送超时	谨慎	先以 tmp_mid、消息历史和实时事件确认是否已落库，再决定重试。
访客 Token 无效	不直接重试原请求	向业务服务端获取新 Token，重新进入访客页。
客服登录态失效	不直接重试	跳转登录，登录成功后重新初始化工作台。
参数/权限/业务校验失败	否	展示 msg，修正输入或权限后由用户重新操作。
限流	可以	遵循提示延迟重试，避免立即并发重放。
服务端 5xx	谨慎	记录上下文；写操作先查询最终状态，避免重复创建。

日志脱敏

排查时可以记录请求路径、HTTP 状态、业务 code、mid、uid（按业务规范脱敏）和请求时间。不得记录完整访客 Token、客服 Session Cookie、密码、API Key、appsecret 或上传文件的私密访问地址。