阻止表单默认提交是弹窗确认的前提，必须监听form的submit事件并调用event.preventdefault()；confirm()后需显式调用form.submit()或发起异步请求；弹窗应置于校验通过之后，避免无效数据被确认。
submit 事件里阻止默认行为是前提
表单直接提交会整页刷新，弹窗确认必须先拦住这个动作。不加 event.preventDefault()，哪怕后面写了 alert() 或 confirm()，页面也已经跳走了。
常见错误是只监听 click 事件绑定在按钮上，但用户按回车也能触发表单提交，所以必须监听 submit 事件，且绑定在 <form></form> 元素上。
- 正确写法：
form.addEventListener('submit', handler) - 错误写法：
button.addEventListener('click', handler)（漏掉回车提交） - 如果用了内联
onsubmit，记得函数末尾返回false，否则默认行为照常发生
confirm() 弹窗后需显式控制提交逻辑
confirm() 只返回布尔值，它本身不拦截也不触发提交——你得自己决定后续动作。很多人以为点了“确定”表单就自动提交了，其实不会。
典型场景：用户点击提交，弹出“确定要提交吗？”，点“取消”就什么也不做，点“确定”才调用 form.submit()（注意这是原生方法，不是触发 submit 事件）。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 不能写
form.dispatchEvent(new Event('submit'))，这又会再次进入监听器，可能造成死循环 - 应该用
form.submit()绕过事件监听，直接提交 - 如果用了 fetch 或 axios 提交，那就在
confirm()为 true 时执行异步请求，不再调用submit()
避免在表单验证失败时也弹窗
弹窗确认是给“操作风险”用的，不是给“输入错误”用的。如果用户邮箱没填、必填项为空，应该先做前端校验，校验失败就别弹确认框，否则体验很怪。
建议把弹窗逻辑放在校验通过之后，比如：
if (form.checkValidity()) {
if (confirm('确认提交？')) {
form.submit();
}
} else {
form.reportValidity(); // 触发浏览器默认提示
}
-
form.checkValidity()返回布尔值，兼容所有 type="email"、required 等原生校验 - 不要用
if (input.value)手动判断，容易漏掉正则、range、pattern 等规则 - 若用了自定义校验（如用户名是否已存在），需等异步结果返回后再决定是否弹窗
移动端 Safari 对 confirm() 的限制要注意
iOS 16.4+ 的 Safari 在非用户手势上下文中禁止弹出 confirm()（比如 setTimeout 里调用），而表单 submit 是用户手势，通常没问题。但如果你在弹窗前加了防抖、节流或异步等待，就可能掉出上下文。
更稳妥的做法是：确认逻辑必须紧贴在事件回调的第一层同步代码中，不嵌套 Promise.then、setTimeout 或 await（除非确保 await 的 Promise 已 resolve）。
- 安全写法：
if (confirm(...)) { form.submit(); }—— 直接写在 submit 回调里 - 危险写法：
setTimeout(() => { confirm(...) }, 0)—— 在 iOS Safari 中静默失败，无弹窗 - 替代方案：用自定义 modal（div + backdrop）代替
confirm()，完全可控，但需额外处理焦点和键盘关闭
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
