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