原生confirm不可靠：不支持样式定制、无法绑定框架状态、阻塞主线程、在ios safari/electron/微前端中常失效，且违反wcag焦点规范；应改用promise封装的自定义弹窗并前置权限校验。
HTML原生alert/confirm在现代前端框架里根本不可靠
直接说结论：浏览器原生的 confirm 对话框**不支持自定义样式、无法嵌入HTML结构、不能绑定Vue/React状态、阻塞主线程且在iframe或PWA中常被禁用**。很多开发者以为“点确认就继续执行”，结果在iOS Safari里点不动，在Electron里弹出两次，或在微前端场景下直接静默失败。
常见错误现象：confirm("确定删除？") 返回 false 但后续逻辑没兜底；用户快速连点导致重复提交；在Chrome扩展content script中调用后无响应。
- 它本质是同步阻塞API，会冻结整个页面渲染和事件循环
- 移动端Safari从iOS 16.4起对非用户手势触发的
confirm直接忽略（比如setTimeout后调用） - Web Components或Shadow DOM内调用时，对话框可能出现在错误层级，甚至被CSS
z-index截断
confirm的替代方案必须手动管理状态流
用Promise封装自定义弹窗不是为了“更好看”，而是为了把“等待用户决策”这个异步动作真正纳入JS控制流。否则你永远得靠全局变量或闭包硬扛状态，一加权限校验或二次确认就崩。
实操建议：
- 不要写
if (confirm(...)) { doSomething() }—— 改成showConfirmDialog().then(() => doSomething()) - 确保弹窗组件有明确的
resolve/reject出口，避免悬空Promise - 在
finally里重置按钮loading态，否则用户连点两次会卡住 - 如果用Vue，别把dialog状态放
v-if里靠响应式切换——要用v-show+显式close()，否则过渡动画和焦点管理全乱
第三方库如react-modal或vue-dialog默认不处理键盘焦点陷阱
WCAG 2.1要求模态框必须锁定Tab键焦点在内部，但绝大多数轻量库默认不启用。用户按Tab跳出确认框、误触背后按钮、屏幕阅读器跳过“取消”按钮——这些都不是UI问题，是合规性风险。
关键参数差异：
-
react-modal必须传shouldCloseOnOverlayClick={false}+ 手动监听Esc并调onRequestClose，否则点击蒙层=绕过确认直接关闭 -
Element Plus的el-dialog默认禁用Esc关闭，但confirm-button-text不支持插槽，没法放带icon的按钮 - 所有库的
aria-labelledby必须指向标题元素ID，否则VoiceOver读不出“确认删除文件？”而只读“对话框”
服务端返回403后前端再弹确认框，时机已错
典型错误链路：用户点删除 → 前端直接confirm → 发请求 → 服务端返回403 → 前端才弹“权限不足”。这等于让用户为一个注定失败的操作做确认。
正确做法是前置判断：
- 把权限字段（如
can_delete: true）随列表数据一起下发，按钮用v-if="item.can_delete"控制显隐 - 若权限需实时校验，先发
HEAD /api/files/{id}查权限，成功后再showConfirmDialog() - 避免在
catch里补弹窗——用户看到的是“删完了？没删成？还是删了一半？”，体验断裂
最易被忽略的一点：确认框文案必须和实际操作严格一致。写“确定删除？”但后端其实是软删除+归档到回收站，用户误以为彻底清空，投诉率会上升。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
