HTML原生confirm()是同步阻塞的，不支持async/await；应改用元素或SweetAlert2等异步友好方案，确保状态校验在弹窗前完成。
HTML原生alert()、confirm()、prompt()不支持自定义样式或异步等待
浏览器内置的对话框是同步阻塞的，调用confirm()后 JS 会暂停执行，直到用户点击“确定”或“取消”。这意味着你不能把它和async/await配合使用，也不能在confirm()后面直接写依赖用户选择的异步逻辑（比如fetch请求）——它根本不会等你“处理完再继续”，而是立刻返回true或false，然后往下走。
常见错误现象：
– 写了await confirm("确定删除？")，报错confirm is not async
– 把confirm()放在if里，但后续代码仍无条件执行（其实是没理解返回值被忽略）
- 正确做法：把后续逻辑包进
if (confirm(...)) { ... }块内，而不是试图“等待”它 - 如果必须异步（例如先校验权限再弹窗），得把弹窗逻辑移到异步链之后，用回调或
then触发 - 所有现代框架（React/Vue）中，应避免直接用
confirm()，改用受控组件实现模态框
用dialog元素实现可交互、可编程的确认对话框
<dialog></dialog>是 HTML5 原生元素，支持showModal()、close()等方法，且不阻塞主线程。但它默认没有“确定/取消”按钮逻辑，需手动绑定事件和状态。
关键点：
– 必须显式调用myDialog.showModal()才能显示，不能靠open属性自动触发（该属性仅作初始状态标记）
– 点击遮罩层或按Esc会触发close事件，但不会自动提交或取消；你需要监听并决定是否执行操作
– returnValue属性可用于传递结果（如"confirm"或"cancel"），但需手动设置
立即学习“前端免费学习笔记（深入）”；
- 示例中不要直接在
<button onclick="dialog.close()"></button>里写逻辑，而应在dialog.addEventListener("close", ...)中统一处理 - 注意兼容性：
<dialog></dialog>在 Safari 中直到 v15.4 才完全支持showModal()，旧版本需降级为display: block模拟 - 若需表单验证（如输入密码确认），应在
submit事件中调用event.preventDefault()，再根据校验结果决定是否dialog.close("confirm")
阻止默认行为时，preventDefault()对dialog关闭无效
很多人误以为给dialog加click事件并调用preventDefault()就能拦截关闭，其实不行。遮罩层点击、Esc、dialog.close()这些行为本身不触发可取消的 DOM 事件，它们直接改变open状态。
真正能拦截的方式只有：
– 监听close事件，在里面调用dialog.showModal()强行重新打开（不推荐，体验差）
– 或更合理地：提前收集用户意图，比如在点击“删除”按钮时先弹出dialog，并在其中提供明确的“确认删除”和“我再想想”两个按钮，不依赖外部关闭动作
- 不要写
dialog.addEventListener("click", e => e.preventDefault())，这只会阻止点击内部内容，对模态框关闭毫无影响 - 如果业务要求“未保存时不许关”，应在
beforeunload或pagehide中提示，而非试图锁死dialog -
dialog.returnValue只在close后可读，且必须由代码主动赋值（如dialog.close("yes")），否则为""
第三方库（如SweetAlert2）为何比原生confirm()更适合复杂确认流
SweetAlert2 返回 Promise，天然适配async/await，而且允许配置图标、输入框、加载状态、自定义 HTML 内容。它底层仍是基于 DOM 操作，但封装了状态管理与事件调度。
典型误用：
– 把Swal.fire()当同步函数用，漏掉await导致逻辑乱序
– 在preConfirm里做异步校验但没return Promise，导致确认按钮一直 loading
-
preConfirm选项必须返回 Promise，否则 SweetAlert2 不知道何时结束校验 - 若要禁用“取消”按钮，设
showCancelButton: false，而不是靠 CSS 隐藏——后者仍可能被Esc触发关闭 - 服务端返回错误时，建议用
Swal.showValidationMessage("xxx")而非alert()，保持 UI 一致性
