本文详解浏览器点击刷新按钮引发表单重复提交的根本原因，并系统讲解 prg（post-redirect-get）模式的工作机制与实现方法，帮助后端开发者从根本上规避重复提交风险。
本文详解浏览器点击刷新按钮引发表单重复提交的根本原因，并系统讲解 prg（post-redirect-get）模式的工作机制与实现方法，帮助后端开发者从根本上规避重复提交风险。
在 Web 开发中，用户提交表单后若直接点击浏览器“刷新”或按 F5 键，常意外触发二次甚至多次提交——这不仅可能造成重复下单、重复扣款、数据冗余等严重业务问题，还暴露了对 HTTP 请求生命周期理解的盲区。其根本原因在于：浏览器的刷新行为本质是重放（replay）上一次发出的 HTTP 请求。
当用户通过 <form method="POST"> 提交数据时，浏览器向服务器发送一个 POST 请求。若后端处理完成后直接返回 200 OK 响应并渲染结果页（如“提交成功”HTML），此时浏览器地址栏仍停留在原 POST 路径（例如 /order），而最后一条历史请求记录就是该 POST 请求。因此，刷新操作会原样重发该 POST 请求，导致表单被再次提交。
✅ 正确解法：PRG（Post-Redirect-Get）模式
该模式通过一次服务端重定向，将“提交后”的最终状态从 POST 转为 GET，从而切断刷新重放 POST 的链路：
// 用户提交 → POST /order POST /order HTTP/1.1 Content-Type: application/x-www-form-urlencoded name=Tom&email=tom@example.com // 服务端处理成功后 → 返回 303 See Other（推荐）或 302 Found HTTP/1.1 303 See Other Location: /order/success // 浏览器自动发起 GET 请求（非重放 POST！） GET /order/success HTTP/1.1
此时，浏览器地址栏变为 /order/success，最后的请求是安全的 GET。无论用户如何刷新，都只会重复执行 GET /order/success —— 不产生副作用，完全符合 REST 原则。
⚠️ 注意事项：
- 必须使用 303 See Other（语义最准确）或 302 Found，不可用 307 Temporary Redirect（它会强制重放原始请求方法，仍可能重发 POST）；
- 重定向前需确保业务逻辑已完整执行（如数据库写入、事务提交），避免重定向后状态不一致；
- 成功页（GET 目标页）应仅展示结果，不处理业务逻辑，也不再接收表单数据；
- 可结合一次性 Token（如 CSRF Token）作双重防护，但 PRG 是架构层最根本的解决方案。
总结：重复提交不是“用户操作失误”，而是 HTTP 协议与浏览器行为的自然结果。掌握 PRG 模式，本质是主动管理客户端请求流——用一次无副作用的重定向，换取整个流程的安全性与可刷新性。这是每个后端开发者必须内化的 Web 基础范式。
