阻止表单默认提交是弹窗确认的前提，必须监听form的submit事件并调用event.preventDefault()；confirm()后需显式调用form.submit()或发起异步请求；弹窗应置于校验通过之后，避免无效数据被确认。
submit 事件里阻止默认行为是前提
表单直接提交会整页刷新，弹窗确认必须先拦住这个动作。不加 event.preventDefault()，哪怕后面写了 alert() 或 confirm()，页面也已经跳走了。
常见错误是只监听 click 事件绑定在按钮上，但用户按回车也能触发表单提交，所以必须监听 submit 事件，且绑定在 <form> 元素上。
- 正确写法：
form.addEventListener('submit', handler) - 错误写法：
button.addEventListener('click', handler)（漏掉回车提交） - 如果用了内联
onsubmit，记得函数末尾返回false，否则默认行为照常发生
confirm() 弹窗后需显式控制提交逻辑
confirm() 只返回布尔值，它本身不拦截也不触发提交——你得自己决定后续动作。很多人以为点了“确定”表单就自动提交了，其实不会。
典型场景：用户点击提交，弹出“确定要提交吗？”，点“取消”就什么也不做，点“确定”才调用 form.submit()（注意这是原生方法，不是触发 submit 事件）。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 不能写
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()，完全可控，但需额外处理焦点和键盘关闭
