错误响应

先判断网络与 HTTP 状态，再按端点 Schema 解析响应。不要依赖统一错误字段或错误文本。

HTTP 处理

结果	是否重试	处理方式
`400`	视端点而定	既可能是输入错误，也可能是依赖或下游失败；先按端点语义判断是否可能已产生部分写入
`503 maintenance`	是，有界退避	等待恢复维护结束，并观察 `/readyz`
其他 `5xx` 或网络超时	条件重试	使用指数退避、抖动、上限和取消
`2xx` 但响应不符合 Schema	否	停止处理并检查版本或合同漂移

常见错误体：

{"msg":"...","status":400}
{"error":"maintenance","message":"restore maintenance is active"}

错误文本不是稳定机器合同；客户端应根据 HTTP 状态和 Schema 分支。

/message/send 必须检查 reason；只有成功 Reason Code 才表示消息被接受。
/channel/messagesyncbatch 必须逐项检查 items[].error，单项失败仍会使用 HTTP 200。
/message/syncack 找不到当前进程保存的 generation 时返回 200，但不会确认任何消息；last_message_seq 不参与实际确认。
多个旧式删除或退出入口在目标不存在时返回 200。把它理解为“期望状态已满足”，不要当成“本次确实删除了一条记录”。

/channel、订阅者 reset、允许/拒绝列表 set，以及 device_flag=-1 的设备退出都会分阶段执行。中途出现 400、5xx、连接断开或超时时，前面的阶段可能已经提交。不要盲目反向操作；保存业务侧期望版本，重新读取可观测状态，并幂等重放期望状态。

Product HTTP 目前只提供普通允许列表的旧式完整读取，不提供普通订阅者、拒绝列表和临时订阅者的对称读回。需要严格协调时，以业务数据库为期望源，并使用受保护的 Manager 查询进行有界核对。

HTTP 成功不代表 CONNECT、SENDACK、实时投递或已读成功。CONNACK 与 SENDACK 应按对应包类型和 Reason Code 单独处理；未知值应停止并报告。