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