API 超时后能直接重试吗？先分清失败与结果未知

按操作决定处理方法#

对允许重试的操作，可使用带随机抖动的指数退避，同时限制次数、单次超时和总体时间。若服务端提供有效的 Retry-After，按其指示等待。不要让 SDK、代理、队列消费者三层各自重试，导致次数相乘。

HiKaRi 视频创建的幂等规则#

依据 视频文档，创建视频使用 POST /v1/videos，也提供 /v1/videos/generations 兼容入口。对同一个业务动作，在第一次提交前生成并持久化 Idempotency-Key，它应是 1～128 个 ASCII 字符。

1
业务 ID → 幂等键 → 提交请求 → 保存任务 ID → 查询任务 → 保存成品

例如使用 Python 的 uuid.uuid4().hex 生成键。相同业务、相同请求体、相同 Key 凭据的安全重发使用同一幂等键；不要每次网络重试生成新键。修改模型、提示词等请求内容应视作新的业务版本，不能强行复用旧键。

请求头示意：

1
Authorization: Bearer <你的 API Key>
2
Content-Type: application/json
3
Idempotency-Key: <已持久化的本次业务幂等键>

这里描述的是视频文档明确提供的规则，不意味着文字、图片或所有第三方接口都自动支持相同幂等行为。幂等有效范围与冲突响应以实际文档和接口为准，不承诺永久去重。

任务队列怎么存状态#

在业务库中为一次用户动作建立唯一记录，保存请求摘要、幂等键、任务 ID、最近一次查询时间和最终状态。消费者重启后从这条记录恢复，先查后续进度。

若提交后未拿到任务 ID，保留“结果未知”，使用同一幂等规则核对，不直接宣告失败并自动另起任务。长时间无法确定时携带脱敏记录联系支持。

媒体生成完成、结算确认和成品存储是不同状态，详见 图片与视频流程。短期重试不能代替业务对账；最终应核对已创建任务与费用，排除重复执行。