应使用<dialog>元素替代原生confirm()，因其可自定义样式、支持Promise封装、无障碍且语义化；第三方库如SweetAlert2适用于需兼容旧浏览器或复杂交互的场景。
HTML原生alert()、confirm()无法自定义样式或行为
浏览器内置的confirm()确实能弹出带“确定/取消”的对话框，但它完全受制于用户代理（UA）——不能改按钮文字、加图标、嵌入输入框，甚至在部分iOS Safari中会阻塞页面滚动。一旦项目要求品牌一致性或交互扩展（比如“记住本次选择”复选框），它就立刻失效。
常见错误现象：confirm()调用后页面假死，Vue/React状态不更新；点击空白处无法关闭；返回值永远是true或false，没法传回输入内容。
- 别试图用
CSS覆盖confirm()——它不在DOM树里，无法选中 - 不要在
async函数里直接await confirm()——它不是Promise，会立即返回 - 移动端慎用：Safari对
confirm()有额外限制，可能静默失败
用dialog元素实现可编程确认对话框
<dialog>是现代HTML标准中唯一原生支持模态交互的语义化元素，支持showModal()、close()、returnValue，且完全可样式化、可聚焦、可无障碍访问。
实操要点：
立即学习“前端免费学习笔记（深入）”；
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 必须用
document.querySelector('dialog').showModal()触发，open属性只是初始状态，不等于已显示 - 点击遮罩层默认不关闭——需手动监听
click事件判断是否点在dialog外 - 关闭时用
dialog.close('confirmed')或dialog.close('canceled')，后续可通过dialog.returnValue读取 - 记得加
role="dialog"和aria-modal="true"提升可访问性
<dialog id="confirm-dialog">
<p>确定要删除这项记录吗？</p>
<button id="confirm-btn">确定</button>
<button id="cancel-btn">取消</button>
</dialog>
<script>
const dialog = document.getElementById('confirm-dialog');
document.getElementById('confirm-btn').onclick = () => dialog.close('confirmed');
document.getElementById('cancel-btn').onclick = () => dialog.close('canceled');
// 使用示例
async function askDelete() {
dialog.showModal();
return new Promise(resolve => {
dialog.addEventListener('close', () => resolve(dialog.returnValue), { once: true });
});
}
// 调用
askDelete().then(res => {
if (res === 'confirmed') console.log('执行删除');
});
</script>
第三方库（如SweetAlert2）比手写dialog更省事的场景
当需要快速支持IE11、统一主题、动画过渡、输入框集成、国际化按钮文本，或已有大量confirm()调用需最小改动迁移时，SweetAlert2这类库反而更稳。
关键差异点：
-
SweetAlert2.fire()返回Promise，天然适配async/await，不用自己包装事件监听 - 支持
input: 'text'、showCancelButton: true等配置项，一行代码搞定复杂表单确认流 - 默认禁用背景滚动、自动聚焦首个可交互元素、ESC键关闭——这些
<dialog>都要手写 - 注意体积：压缩后约90KB，若仅需确认功能，
<dialog>零依赖更轻量
确认操作与业务逻辑解耦的关键：别在对话框里写具体操作
最容易被忽略的其实是架构层面的问题：把deleteUser(id)直接写进“确定”按钮的onclick里，会导致复用困难、测试难覆盖、错误处理分散。
正确做法是让对话框只负责“问”，业务逻辑由调用方决定：
- 对话框组件接收
onConfirm和onCancel两个函数作为props或参数 - 点击“确定”只触发
onConfirm()，不关心它内部是发请求还是跳路由 - 这样同一个确认框能复用于删除、退出编辑、清空缓存等多个场景
- 单元测试时可直接mock这两个回调，无需模拟DOM点击
复杂点在于：异步确认（比如先校验再弹窗）需要状态暂存；连续多次调用需防重复弹窗；服务端返回403时，确认框不该再出现——这些都得在调用层控制，不是对话框本身的责任。
