防重复提交本质是保障接口幂等性，核心是服务端唯一性校验；推荐基于Token（UUID/Snowflake生成，Redis存储并原子校验删除）、参数+时间戳+签名（HMAC-SHA256，防重放）、数据库唯一约束兜底及@Idempotent注解统一拦截处理。
防重复提交本质上是保证接口的幂等性，即同一请求无论执行多少次，结果都一致。Java中实现的关键在于识别“相同请求”并拦截后续重复调用，核心思路是服务端对请求做唯一性校验，而非依赖前端限制。
基于Token的防重提交（推荐）
客户端在提交表单前先向服务端申请一个一次性token，服务端生成并存入Redis（带过期时间），同时返回给前端；提交时将token作为参数传入，服务端校验token是否存在且未被使用，验证通过则删除token并处理业务逻辑。
- Token建议用UUID或Snowflake ID生成，避免可预测性
- Redis中以token:xxx为key，value可设为用户ID或空字符串，过期时间通常设为15–30分钟
- 校验与删除需原子执行，推荐使用Redis Lua脚本或RedisTemplate.opsForValue().delete()配合exists判断
- 若校验失败，统一返回400 Bad Request及提示“请求已处理，请勿重复提交”
基于请求参数+时间戳+签名的幂等校验
适用于无页面跳转的API场景（如App、小程序调用）。客户端将关键业务参数、当前毫秒级时间戳、随机nonce拼接后，用约定密钥进行HMAC-SHA256签名，服务端复现签名逻辑比对，并校验时间戳是否在允许偏移范围内（如±5分钟），同时用userId:timestamp:nonce为key写入Redis防止重放。
将一个或多个 UI 原型图、线框图、产品截图或设计稿转换为标准化、可直接交付的 PRD 风格文档，供产品、设计、前端和测试共同使用。适用于 Codex 需要分析 PC 网页、桌面端、移动端、响应式页面、独立弹窗、表单、表格、看板、数据大屏或多页面流程截图，还原页面结构与交互，强制套用固定文档模板，抽取跨页面共享规则，或把一组原型沉淀为单页规范文档加整体业务流程文档的场景。不适用于纯视觉审美点评、代码实现、接口设计、埋点方案、竞品分析或无 UI 输入的业务需求创作。
- 时间戳和nonce必须参与签名，防止篡改和重放
- Redis key需包含用户标识，避免不同用户间冲突
- 该方式不依赖会话，适合分布式无状态服务
数据库唯一约束兜底
对于创建类操作（如下单、发券），在业务表中增加唯一索引字段（如order_no、trade_no、biz_id + user_id组合），即使前置校验失效，数据库层面也能阻止脏数据写入。配合异常捕获，将DuplicateKeyException转换为友好的业务错误提示。
立即学习“Java免费学习笔记（深入）”；
- 唯一字段应具备业务语义，避免单纯用UUID导致索引膨胀
- 注意MySQL的INSERT IGNORE / ON DUPLICATE KEY UPDATE行为差异
- 该方式是最终防线，不能替代前置防重，否则用户体验差（请求已到DB才失败）
拦截器+注解统一处理（工程化实践）
定义@Idempotent注解，标注在需要幂等的方法上；编写Spring MVC拦截器或AOP切面，在执行前解析请求参数、提取token或签名信息，调用统一校验服务（封装Redis操作）；校验失败抛出IdempotentException，由全局异常处理器返回标准响应。
- 注解可支持配置超时时间、校验模式（token/sign）、自定义key生成策略
- 避免在切面中耦合具体存储实现，通过接口抽象RedisClient或IdempotentStore
- 日志记录重复请求的traceId、IP、参数摘要，便于问题追溯
