Java防重复提交核心是服务端“一次有效、多次无效”，常用Token机制（生成UUID/SecureRandom令牌存Redis/session并校验删除）、时间戳+签名防重放、数据库唯一约束兜底，前端禁用按钮仅为辅助。
Java中防止表单重复提交，核心思路是“一次有效、多次无效”，关键在于服务端识别并拦截重复请求，而不是依赖前端限制（如按钮置灰）——因为前端控制容易被绕过。
服务端生成唯一令牌（Token）
用户访问表单页时，后端生成一个随机且唯一的token，存入session或Redis，并将token嵌入表单的隐藏字段中。提交时，后端比对token是否匹配且未使用过。
- 生成token建议用UUID或SecureRandom，确保不可预测
- 校验通过后立即从session/Redis中删除该token，避免二次使用
- token需设置合理过期时间（如10分钟），防止长期占用存储
基于时间戳+参数签名防重放
适用于前后端分离场景（如REST API）。客户端在请求头或参数中携带当前时间戳和签名（如对参数+密钥+timestamp做MD5/HMAC），服务端验证：时间戳是否在允许偏移范围内、签名是否正确、该timestamp是否已处理过。
- 服务端可将合法timestamp存入Redis，设置短过期（如60秒），实现“窗口内去重”
- 签名密钥不暴露给前端，由网关或认证服务统一管理
- 注意处理服务器时钟漂移，建议以服务端时间为准
数据库唯一约束兜底
对业务上有天然唯一性的操作（如用户注册、订单创建），在数据库层面添加唯一索引（如user_email、order_no）。即使并发请求穿透了上层拦截，数据库也能抛出DuplicateKeyException，后端捕获后返回友好提示。
- 适合最终一致性要求不高、且有明确业务唯一键的场景
- 不能替代token机制，仅作为最后一道防线
- 异常需统一处理，避免堆栈信息泄露给前端
前端配合：按钮禁用 + 防抖不是解决方案
按钮点击后置灰、禁用提交按钮，只是提升用户体验，不能替代服务端校验。用户仍可通过刷新页面、重复发包、脚本调用等方式绕过。
- 防抖（debounce）只对同一操作的连续触发有效，无法防止网络超时后用户手动重试
- 真正的幂等性必须由服务端保障，前端只是辅助
- 建议在按钮禁用的同时，显示“处理中…”提示，降低用户焦虑
基本上就这些。Token机制最常用也最可靠，搭配数据库唯一约束，能覆盖绝大多数重复提交场景。不复杂但容易忽略的是token的生命周期管理和存储选型——session适合单机，分布式环境务必用Redis或类似共享存储。
