alert、confirm、prompt是BOM提供的原生阻塞式对话框函数：alert仅显示提示并返回undefined；confirm返回true/false用于确认分支；prompt返回输入字符串或null，三者均不可定制样式、不支持无障碍、易被现代浏览器限制，现代开发应优先使用Modal、Toast等可访问、可测试的替代方案。
JavaScript 中的 alert、confirm 和 prompt 是浏览器对象模型（BOM）提供的原生对话框函数，用于快速实现用户交互。它们使用简单，但存在明显局限——现代开发中基本被自定义模态框、Toast 提示、表单验证等更可控的方式替代。
alert：只读提示，强制中断执行
显示带“确定”按钮的纯文本提示框，无返回值（返回 undefined），且完全阻塞后续 JavaScript 执行和页面交互，直到用户点击“确定”。
- 用法：
alert("操作成功！") - 适用场景：极简调试、紧急警告（如登录失败后强提醒）、教学演示
- 问题：打断用户操作流；无法关闭或跳过；样式不可定制；在移动设备上体验差
confirm：二选一确认，返回布尔值
弹出含“确定”和“取消”按钮的对话框，用户点击后返回 true 或 false，常用于流程分支控制。
- 用法：
if (confirm("删除后不可恢复，确定吗？")) { doDelete(); } - 优势：逻辑清晰，适合轻量级确认动作（如退出编辑、清空缓存）
- 缺点：同样阻塞执行；文案与按钮不可改；无法添加图标或额外说明；多语言支持弱
prompt：带输入框的交互，返回字符串或 null
显示一个含提示文字、输入框及“确定/取消”按钮的对话框。用户点“确定”时返回输入内容（空字符串也有效），点“取消”或关闭则返回 null。
立即学习“Java免费学习笔记（深入）”；
- 用法：
const name = prompt("请输入姓名", "游客"); - 注意：默认值仅作占位，不参与校验；空输入和取消需分别判断（
name === null表示取消，name === ""表示输入为空） - 风险：易被用户忽略或误填；无输入限制（如长度、格式）；移动端软键盘唤起不稳定
为什么现代前端开发不推荐使用它们
这些函数本质是浏览器强干预式 UI，与当前 Web 应用的用户体验目标背道而驰：
- 破坏用户体验：强制聚焦、阻塞主线程，导致页面“卡死”，尤其在单页应用（SPA）中可能中断路由跳转或状态更新
- 无法定制与适配：不能修改样式、按钮文字、图标、动画，也不支持响应式布局，在深色模式、无障碍访问（如屏幕阅读器）方面完全缺失
-
安全性隐患：所有内容以纯文本渲染，不自动转义 HTML，若传入用户数据可能引发 XSS（例如
alert(userInput)） - 不符合设计系统规范：企业级项目通常有统一的提示组件库（如 Ant Design 的 Modal/Message、Element Plus 的 ElMessageBox），便于主题统一与行为管理
- 测试与维护困难：依赖真实浏览器环境，自动化测试中难以模拟点击；逻辑耦合在 DOM 弹窗中，不利于单元测试和状态驱动开发
不复杂但容易忽略：它们不是“错”，而是“过时的快捷键”。真正需要交互时，用 Modal 封装业务逻辑，用 useToast 管理轻提示，才是可持续的做法。
