必须监听form submit事件并统一处理所有提交路径，禁用按钮需按表单实例独立控制，后端token须按表单类型隔离校验。
form submit 事件监听必须覆盖所有提交路径
只给某个按钮加 onclick 或只禁用单个 button[type="submit"]，根本拦不住跨表单重复提交。用户可能用回车触发表单、点其他 type="submit" 按钮、甚至用 DevTools 手动调用 form.submit() —— 这些都绕过按钮级控制。
正确做法是监听整个 form 的 submit 事件，并统一处理所有提交入口：
- 用
form.querySelectorAll('button[type="submit"], input[type="submit"]')找出全部提交控件，全部设disabled = true - 不要依赖
event.target判断哪个按钮被点——它在回车或form.submit()调用时可能是null或form元素本身 - 禁用后别改
textContent就完事，建议加aria-busy="true"属性，兼顾可访问性
多个表单共存时防重状态不能全局共享
页面上有 form#order 和 form#refund 两个表单，如果用一个全局变量 isSubmitting 控制，就会出现：A 表单正在提交，B 表单按钮被误锁；或者 A 提交失败后恢复了按钮，B 却还卡在禁用态。
解决方案是把锁状态绑定到表单实例上：
立即学习“前端免费学习笔记（深入）”；
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 给每个
form元素挂载自定义属性，如form.dataset.isSubmitting = "true" - 在
submit处理器里先检查form.dataset.isSubmitting === "true"，是则直接return - 请求完成（
fetch().finally()或axios().finally()）后，再设为"false" - 避免用闭包变量或模块级
let，它们无法区分不同表单的生命周期
后端 token 必须按表单类型隔离校验
前端传来的 submit_token 如果只是全局生成一次、所有表单共用，那用户开两个标签页填同一类表单，第二个会因 token 已消费而失败；更糟的是，订单表单和退款表单用了同一个 token，就等于把防重逻辑串在一起，破坏业务边界。
服务端下发和校验 token 时要明确分形：
- token 值应包含表单标识前缀，比如
order_form_f8a2e7d1...和refund_form_9c4b4f0a... - session 中存储 token 时，用
session["token:order_form"]和session["token:refund_form"]分开存取 - 校验失败返回的 HTTP 状态码必须是
400 Bad Request，且响应体带明确字段：{"error": "invalid or consumed submit_token", "form": "order_form"} - 前端收到该错误，应只恢复对应表单的按钮，不波及其他
PRG 模式对跨表单场景的实际约束
PRG（POST-Redirect-GET）能解决 F5 刷新重复提交，但它要求每次 POST 后必须跳转，这在多表单同页场景下很难落地——比如一个页面同时展示「新建订单」和「批量退款」两个独立表单，你不可能让其中一个提交后整页跳走，打断另一个表单的操作流。
所以 PRG 不是银弹，它只适用于「单主表单 + 结果页」结构。跨表单场景下真正能靠得住的只有两件事：
- 前端：每个
form独立监听、独立锁、独立恢复 - 后端：每个表单类型配独立 token + 独立幂等键（如
req_id绑定user_id + form_type + timestamp）
最容易被忽略的是：token 过期时间得按表单操作耗时动态调整。比如退款审核可能要人工介入，token 有效期得设成 30 分钟；而地址修改这种秒级操作，5 分钟就够了。硬写死全局 10 分钟，不是太短就是太松。
