PRG模式通过POST→Redirect→GET流程防止刷新重复提交，核心是服务器返回303重定向到无副作用的GET页面，使刷新仅重载结果页而非重发POST。
为什么表单提交后刷新页面会重复提交
浏览器刷新时会重发上一次的请求，如果上次是 POST 表单提交，就会再次执行提交逻辑——这不是后端没防重，而是 HTTP 协议本身的行为。用户点一次“提交”，F5 一刷，订单创建了两次、支付扣了两笔，问题出在请求方法和浏览器缓存机制上。
常见错误现象：400 Bad Request（某些框架拦截）、500（数据库唯一约束冲突）、或完全没报错但业务数据异常重复。
- GET 请求刷新不会重复提交（只是重读），但表单默认用 POST
- 前端加
disabled按钮只能防用户连点，拦不住刷新 - 后端用时间戳/UUID 做幂等性校验，是补救，不是根治
PRG 模式怎么用：POST → Redirect → GET 流程
核心就是不让浏览器停留在 POST 响应页。提交成功后，服务器不直接返回 HTML，而是返回一个 302 Found 或 303 See Other 响应，把浏览器重定向到一个只读的 GET 页面（比如“提交成功”页）。
这样用户刷新时，当前 URL 是 GET 地址，刷新只会重载结果页，不会触发二次提交。
DeepBI DHTML 页面生成器
下载
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
-
303是 PRG 的推荐状态码，明确表示“用 GET 去取结果”，兼容性比302更稳妥 - 重定向目标 URL 应该是无副作用的，比如
/order/success?id=123，而不是又一个表单页 - 服务端需把关键信息（如成功提示、订单号）通过 URL 参数、session 或临时 token 传过去，避免丢失上下文
后端实现时容易漏掉的细节
PRG 不是加一行 redirect() 就完事。很多框架默认行为会悄悄破坏它。
- Django 中如果用了
HttpResponseRedirect但没清 session 消息，下个 GET 请求可能拿不到 success 提示；得配合messages.success(request, ...)+ 模板中消费 - Express.js 如果在
res.redirect()前写了res.send()或没结束响应，会抛Error [ERR_HTTP_HEADERS_SENT] - PHP 的
header("Location: ...")必须在任何输出之前调用，否则报headers already sent - 重定向后的 GET 接口要能处理“无参数访问”，比如用户手动输入 /success 地址，不能直接 500
前端要不要配合？简单做比不做强
PRG 主力在后端，但前端稍作配合能提升体验和健壮性。
- 提交按钮加
disabled+ 文字变“提交中…”——防手抖连点，不影响 PRG 逻辑 - 用
fetch()提交后手动window.location.href = "/success"，等价于服务端 redirect，但绕过了服务端控制，不推荐作为主方案 - 不要用
history.pushState()模拟跳转来替代真实 redirect，浏览器刷新仍会重发原始 POST - 表单加
autocomplete="off"对防重复无用，别浪费这个精力
真正关键的是后端那一次 303 响应是否干净发出、是否带对上下文、是否指向安全的 GET 端点。其他都是锦上添花，别本末倒置。
