PHP表单重复提交的根源是HTTP无状态导致浏览器刷新/F5/重试重发POST请求，须用session+token实现幂等控制：渲染时生成唯一token存session并嵌入表单，提交时比对且用完即删。
PHP 表单重复提交的典型表现和根源
用户点一次“提交”，后端却收到两条甚至多条请求，日志里看到重复的 INSERT 或 UPDATE，订单号重复生成，支付接口被调两次——这不是网络延迟或前端没禁用按钮的问题，而是服务端没做幂等控制。根本原因在于：HTTP 是无状态协议，浏览器刷新、后退、F5、网络重试都会原样重发上一个 POST 请求，而 PHP 默认对此毫无感知。
用 session + token 实现最简可靠的防重逻辑
核心思路是：每次渲染表单前生成唯一 token，存入 $_SESSION，同时写进表单隐藏域；提交时比对客户端传来的 token 和服务端存储的是否一致，且用完即删（避免多次校验）。
- 必须在
session_start()后操作$_SESSION，否则token无法持久化 -
token建议用bin2hex(random_bytes(16))生成，别用md5(time())或uniqid()，后者可预测、易碰撞 - 校验失败后要立即
unset($_SESSION['form_token'])，否则同一 token 可被反复利用 - 示例片段：
$token = bin2hex(random_bytes(16));<br>$_SESSION['form_token'] = $token;
表单中：<input type="hidden" name="token" value="<?=$token?>">
为什么不能只靠前端 disabled 按钮或 JS 防重
前端拦截只是体验优化，完全不可信。用户禁用 JS、用 curl 直接 POST、抓包重放请求，都能绕过所有前端限制。真实场景中，90% 的重复提交来自非恶意行为：比如支付页加载慢，用户反复点击“确认支付”，或者手机端误触导致两次触发 submit 事件。
- Chrome 浏览器在页面未完全加载完成时按 F5，可能重复发送上一个 POST
- 某些安卓 WebView 对
history.back()处理异常，返回表单页时自动重提交 - 移动端键盘回车、语音输入完成都可能触发多次 submit，JS 绑定的
click或submit事件监听未必全覆盖
token 过期与并发提交的边界情况处理
单次 token 用完即焚是安全底线，但会带来两个现实问题：用户开多个标签页填同一表单、页面长时间未提交导致 token 过期。这时候不能简单报错“非法请求”，得兼顾可用性。
立即学习“PHP免费学习笔记（深入）”；
- token 存储时加时间戳，比如
$_SESSION['form_token'] = ['value' => $token, 'expires' => time() + 600]，校验前先判断是否超时 - 如果用户在 A 标签页提交成功，B 标签页再提交，应返回明确提示：“表单已提交，请勿重复操作”，而不是 500 错误
- 高并发下（如秒杀），单个 session token 不足以支撑分布式部署，此时需换用 Redis + 唯一业务 ID（如订单号）做原子 setnx 校验
真正难的不是生成 token，而是把 token 生命周期、错误反馈、多端一致性这些细节串成闭环。漏掉任意一环，防重就形同虚设。
