表单提交需防重复请求：点击后立即禁用按钮并改文字，配合守卫变量和幂等设计；优先用FormData构造数据；用button type="submit"替代input；校验失败时必须在submit事件中调用event.preventDefault()。
表单提交时如何避免重复发请求
用户点一次提交按钮，后端却收到三四个重复请求——这通常不是网络延迟导致的，而是前端没做防抖或禁用控制。浏览器默认不会阻止用户反复点击 submit 按钮，尤其在表单校验快、接口响应慢的场景下特别明显。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 点击后立即将
submit按钮设为disabled，并可同步改文字（如“提交中…”），防止视觉上仍可点击 - 不要只靠 CSS 的
pointer-events: none，它不阻止键盘回车提交或脚本触发 - 如果用了
fetch或axios，应在submit事件处理器开头加个守卫变量（如let isSubmitting = false），发请求前判断并提前 return - 服务端也得有幂等设计（比如用
idempotency-key请求头），但前端拦截是第一道也是最有效的防线
用 FormData 提交比拼接 URL 更稳妥
很多人习惯把表单字段手动拼成 key=value&key2=value2 字符串，再用 fetch 发 POST，但这容易出编码问题、丢失文件字段、且不兼容 enctype="multipart/form-data" 场景。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 直接用
new FormData(formElement)构造数据，它自动处理空值、文件、编码和边界 - 如果需要额外字段，用
formData.append('token', 'xxx')，别试图把它转成 JSON 再塞进去 - 注意：
FormData对象不能被JSON.stringify，否则会得到空对象；调试时可用for (let [k, v] of formData.entries()) console.log(k, v) - 当后端要求
Content-Type: application/json时，才需要手动序列化——但这时已不属于“原生表单提交”范畴，得换思路
button type="submit" 和 input type="submit" 有啥区别
两者都能触发表单提交，但行为细节不同，尤其在无障碍和移动端上容易翻车。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 优先用
button type="submit"：支持嵌套 HTML（比如带图标或加载动画）、语义更明确、iOS Safari 对它的 focus/keyboard 提交支持更稳 - 避免用
input type="submit"做复杂 UI，它内部无法插入元素，CSS 控制也受限（比如不能用::before加图标） - 如果用了
button却没写type属性，默认是type="submit"—— 在表单里可能意外触发提交，务必显式声明 - 所有提交按钮都应有
name和value，否则某些旧版 PHP 后端收不到按钮标识（比如区分“保存”还是“草稿”）
提交前校验失败，为什么还会发请求
常见现象：JS 校验提示“邮箱格式错误”，但 Network 面板里依然看到请求发出——说明 event.preventDefault() 没生效，或者校验逻辑没拦住默认行为。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 必须在
form.addEventListener('submit', handler)里调用event.preventDefault()，且要在校验失败分支里执行，不能只在成功分支写 - 别在
click事件上做校验并手动submit()，这样绕过了表单原生验证（如required、pattern），也容易漏掉enter键提交 - 启用原生
checkValidity()：在 submit 处理器开头写if (!form.checkValidity()) return event.preventDefault()，它会触发浏览器气泡提示，且兼容性好 - 注意：Chrome 99+ 开始对
reportValidity()的样式支持变弱，如有定制提示需求，建议用自定义 tooltip +setCustomValidity
真正难的不是“怎么发请求”，而是“怎么确保只发一次、只在该发的时候发”。很多看似后端的问题，其实卡在按钮状态没锁死、校验没阻断、或 FormData 构造方式不对这些细节上。
