连点 5 次「生成」，实际执行几次、花几笔钱？
用户会重复点
"提交"按钮点两下 ✔、网络慢时反复刷新 ✔、多设备同时操作 ✔ ——
AI 功能里，重复提交的代价比普通接口高得多 ✗：每次都可能真的花一笔钱 ✔。
并发与重复提交要显式处理 ✔，不能指望用户手稳 ✔。
一、三层防护（缺一不可）
1. 前端：提交后置灰按钮 + 显示进行中状态 ✔（最直接 ✔）；
2. 幂等键：同一逻辑请求带同一 idempotency_key ✔（服务端去重 ✔ —— 见接线那篇 ✔）；
3. 配额与限流：同一用户并发上限（例如 1~2 个同时进行 ✔ —— 见多租户限流那篇 ✔）。
只做前端是不够的 ✗ —— 接口直接调用、脚本重放都能绕过 ✔。
二、幂等键怎么定
```
key = hash(user_id + feature + 归一化后的输入 + 客户端请求序号)
```
· 相同 key 的重复请求 → 返回第一次的结果 ✔（而不是重新生成 ✔）；
· 有效期（例如 10 分钟 ✔ —— 用户确实想再跑一次时要能跑 ✔）；
· 要能显式"重新生成" ✔（带新 key ✔ —— 但界面要提示会再消耗额度 ✔）。
三、多设备/多标签页
· 同一会话在两处编辑 → 用版本号检测冲突 ✔（至少提示"另一处已更新" ✔ —— 见状态与恢复那篇 ✔）；
· 同一用户两处提交 → 幂等键含客户端实例标识 ✔，或明确提示"已有一个任务在进行" ✔。
四、该观测什么
· 重复提交拦截率（拦截了多少次真实重复 ✔ —— 这就是省下来的钱 ✔）；
· 并发上限触发次数（是不是设得太紧 ✔）；
· "重新生成"使用率（用户确实需要多试 ✔ → 说明首次成功率不够 ✔）；
· 因重复提交产生的成本占比 ✔（异常升高要查前端 ✔）。
五、三个反模式
· 只靠按钮置灰 ✗；
· 幂等键用时间戳 ✗（每次都不同，等于没有 ✔ —— 这是最常见的假实现 ✔）；
· 重复提交直接报错 ✗（应该返回已有结果 ✔，用户不关心是谁先发的 ✔）。
一条判据
> 连点 5 次"生成" ✔，实际执行几次、花几笔钱 ✔？
> 超过 1 次，说明幂等没做对 ✗。
本文由云枢 AI导航整理，内容以官方来源为准。
相关文章
顺序阅读
← 上一篇：把评测结论写进发布说明
下一篇：把检索范围交给用户：透明的范围控制 →
第 140 / 171 篇