PHP表单重复提交的根源是缺乏服务端防重机制，典型表现为后端收到多条相同数据、日志中SQL执行多次、支付接口被重复调用；解决需用session+随机token实现生成、嵌入、校验销毁三步闭环。
PHP 表单重复提交的典型表现和根源
用户点一次提交按钮，后端收到多条相同数据；日志里看到 INSERT 或 UPDATE 执行了两遍；支付接口被调用两次导致扣款异常。这不是浏览器问题，也不是网络延迟导致的“假重复”，而是因为表单没做防重逻辑——用户刷新页面、点返回再提交、或禁用 JS 后反复点击，$_POST 都会照常送达。
- 表单没带唯一标识，服务端无法区分“同一请求”和“新请求”
- 没在接收入口校验并消耗 token，token 一直有效就等于没设防
- 把防重逻辑写在前端（比如按钮置灰）纯属心理安慰，绕过 JS 几乎零成本
用 session + uniqid() 生成一次性 token 的实操要点
核心就三步：生成 → 塞进表单 → 提交时比对并销毁。别用时间戳或自增 ID，它们可预测；也别把 token 存数据库，小项目没必要，反而拖慢响应。
- 在表单输出前生成：
$_SESSION['form_token'] = bin2hex(random_bytes(32));（比 uniqid() 更安全）
- 表单里加隐藏字段：
- 提交后立刻验证并清空：
if ($_POST['token'] === $_SESSION['form_token']) { unset($_SESSION['form_token']); / 处理业务 / }
- 一定要用
=== 严格比较，避免类型转换绕过（比如 "0" == false）
CSRF token 和防重复提交 token 能共用吗？
能，但不推荐混用。CSRF token 防的是跨站伪造请求，生命周期可以稍长（比如整个登录会话），而防重 token 必须“一次一换”。共用会导致两种情况出问题：
用户开两个标签页填同一张表单，第二个提交必然失败（因为第一个已消耗 token）
如果用户提交失败（如校验不通过），你没重新生成 token，他刷新页面再提就会卡死
独立命名更清晰：$_SESSION['csrf_token'] 和 $_SESSION['submit_token']
-
表单渲染时，只更新 submit_token；CSRF token 可复用，除非用户登出或超时
错误页返回时，记得补上新的 submit_token，否则用户改完再提还是 400
为什么用 $_SESSION 而不用 $_COOKIE 或数据库存 token？$_SESSION 是最平衡的选择：服务端存储、无需额外查询、天然绑定用户会话。用 $_COOKIE 存 token 就等于把钥匙贴在门上——攻击者复制 cookie 就能重放；用数据库则每次提交都要查一次，QPS 上去后容易成瓶颈。
- Session 默认文件存储，高并发下可能有锁争用，但防重场景本身不是高频路径，影响有限
- 如果用了 Redis 做 session handler，性能完全没问题，且天然支持分布式
- 别把 token 放 URL 参数里（比如
?token=xxx），它会进访问日志、代理缓存、Referer，泄露风险极高
session + uniqid() 生成一次性 token 的实操要点
核心就三步：生成 → 塞进表单 → 提交时比对并销毁。别用时间戳或自增 ID，它们可预测；也别把 token 存数据库，小项目没必要，反而拖慢响应。
- 在表单输出前生成：
$_SESSION['form_token'] = bin2hex(random_bytes(32));（比uniqid()更安全） - 表单里加隐藏字段：
- 提交后立刻验证并清空：
if ($_POST['token'] === $_SESSION['form_token']) { unset($_SESSION['form_token']); / 处理业务 / } - 一定要用
===严格比较，避免类型转换绕过（比如"0" == false）
CSRF token 和防重复提交 token 能共用吗？
能，但不推荐混用。CSRF token 防的是跨站伪造请求，生命周期可以稍长（比如整个登录会话），而防重 token 必须“一次一换”。共用会导致两种情况出问题：
用户开两个标签页填同一张表单，第二个提交必然失败（因为第一个已消耗 token）
如果用户提交失败（如校验不通过），你没重新生成 token，他刷新页面再提就会卡死
独立命名更清晰：$_SESSION['csrf_token'] 和 $_SESSION['submit_token']
-
表单渲染时，只更新 submit_token；CSRF token 可复用，除非用户登出或超时
错误页返回时，记得补上新的 submit_token，否则用户改完再提还是 400
为什么用 $_SESSION 而不用 $_COOKIE 或数据库存 token？$_SESSION 是最平衡的选择：服务端存储、无需额外查询、天然绑定用户会话。用 $_COOKIE 存 token 就等于把钥匙贴在门上——攻击者复制 cookie 就能重放；用数据库则每次提交都要查一次，QPS 上去后容易成瓶颈。
- Session 默认文件存储，高并发下可能有锁争用，但防重场景本身不是高频路径，影响有限
- 如果用了 Redis 做 session handler，性能完全没问题，且天然支持分布式
- 别把 token 放 URL 参数里（比如
?token=xxx），它会进访问日志、代理缓存、Referer，泄露风险极高
用户开两个标签页填同一张表单，第二个提交必然失败（因为第一个已消耗 token）
如果用户提交失败（如校验不通过），你没重新生成 token，他刷新页面再提就会卡死
独立命名更清晰：$_SESSION['csrf_token'] 和 $_SESSION['submit_token']
表单渲染时，只更新 submit_token；CSRF token 可复用，除非用户登出或超时
错误页返回时，记得补上新的 submit_token，否则用户改完再提还是 400
$_SESSION 而不用 $_COOKIE 或数据库存 token？$_SESSION 是最平衡的选择：服务端存储、无需额外查询、天然绑定用户会话。用 $_COOKIE 存 token 就等于把钥匙贴在门上——攻击者复制 cookie 就能重放；用数据库则每次提交都要查一次，QPS 上去后容易成瓶颈。
- Session 默认文件存储，高并发下可能有锁争用，但防重场景本身不是高频路径，影响有限
- 如果用了 Redis 做 session handler，性能完全没问题，且天然支持分布式
- 别把 token 放 URL 参数里（比如
?token=xxx），它会进访问日志、代理缓存、Referer，泄露风险极高
防重的核心不在“怎么生成 token”，而在“是否每次提交都强制刷新并校验”。最容易漏掉的是：表单校验失败后没重置 token，或者 AJAX 提交后没手动清 session —— 这时候 token 还在，用户换个方式再提就穿帮了。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
