LiblibAI官方未提供全局幂等支持，需自行实现防重机制：前端生成唯一idempotency_key，后端用Redis SET NX原子校验，重试时复用原始key。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
在使用LiblibAI API批量生成图像或执行模型推理时，网络抖动、前端连点、重试逻辑失控会导致同一任务被多次提交，触发多次计费——哪怕你只点了一次“生成”，账户却扣了三笔费用。
确认LiblibAI是否已内置幂等机制
登录LiblibAI开发者控制台 → 进入「API文档」→ 查看「/v1/generate」等核心接口的请求参数说明。若文档明确标注支持 【idempotency_key】 字段（如“传入唯一字符串，服务端将据此拒绝重复请求”），则说明平台已提供基础幂等能力；否则需自行构建防重层。
注意：截至2026年9月20日，LiblibAI官方文档未公开声明全局幂等支持，【不可依赖服务端自动去重】。
前端生成并透传防重Token
方法一：页面加载时主动获取Token
向你的后端服务发起 GET /api/anti-replay-token 请求，返回一个带过期时间（建议5分钟）的UUIDv4字符串，存入页面内存（非localStorage，避免多标签页冲突）。
方法二：表单提交前动态生成
在点击“生成图像”按钮的瞬间，用 crypto.randomUUID() 生成 token，并立即写入请求体：{"prompt":"a cat","model_id":"sd-xl","idempotency_key":"f8a3b2c1-..."}
这一步必须在 fetch 发起前完成，且每个请求的 idempotency_key 绝对不可复用——哪怕两次请求内容完全相同，也必须用两个不同key。
后端校验与缓存拦截（关键防线）
第一步：解析请求头或body中的 idempotency_key 字段
第二步：检查 Redis 中是否存在键为 liblib:ipk:{idempotency_key} 的记录
第三步：若存在，直接返回 409 Conflict + { "error": "duplicate_request", "ref_id": "req_abc123" }
第四步：若不存在，执行以下原子操作：
① 使用 SET key value EX 300 NX 命令写入Redis（300秒过期，NX确保仅首次写入成功）
② 成功后才转发请求至LiblibAI API
③ 转发失败时不清除该key，防止重试穿透
⚠️ 注意：必须用 Redis 的 SET … NX 原子指令，普通先查后设会导致竞态条件——两个并发请求同时查到“不存在”，然后都写入，最终仍会扣两次费。
客户端重试策略必须带原始Token
当收到 502/504 等网关错误时，前端应原样重发原始请求（含最初生成的 idempotency_key），而不是重新生成新key再发。重试次数建议限制为1次，超时时间设为8秒以上——LiblibAI图像生成通常耗时3～7秒，过短重试反而增加重复概率。
fetch('/api/liblib/generate', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
prompt: 'cyberpunk city',
idempotency_key: window.currentIdempotencyKey // 复用初始值
})
});
