alert、confirm、prompt 是浏览器提供的 JavaScript 全局函数，非 HTML 标签，用于弹窗交互；它们阻塞主线程、样式不可定制、prompt 在非 HTTPS 环境被禁用，现代项目应优先使用 Toast、Modal、表单等可访问、可定制的替代方案。
直接调用 alert、confirm、prompt 就能弹窗，但它们不是 HTML 标签，而是浏览器提供的 JavaScript 全局函数
很多人在写 <button onclick="alert('hi')"> 时以为这是 HTML 功能，其实背后是 JS 在执行。HTML 本身不提供弹窗能力，必须通过 JS 调用这些函数——哪怕只是内联写在 onclick 里，也已进入 JS 执行上下文。
常见错误现象：alert 点击没反应？检查是否被浏览器拦截（比如在非用户手势触发的异步回调中调用）、或脚本根本没加载成功；prompt 在现代 Chrome/Firefox 中已对非安全上下文（HTTP）禁用，仅 HTTPS 页面可用。
-
alert只接受一个字符串参数，传对象会自动调用.toString()，比如alert({a:1})显示[object Object] -
confirm返回布尔值：true表示用户点了“确定”，false表示“取消”或关闭弹窗 -
prompt第二个参数是默认输入值（可选），但 iOS Safari 会忽略它；如果用户点取消或清空后确认，返回null（不是空字符串）
confirm 和 prompt 的返回值必须显式判断，不能只靠“弹出来”就认为用户已确认
典型误用：if (confirm('删除？')) { doDelete(); } 看似没问题，但若用户快速连点两次“取消”，或弹窗被系统焦点抢占导致未响应，逻辑仍可能意外跳过。更稳妥的做法是把返回值赋给变量再判断，并考虑添加 loading 状态防重复提交。
- 不要写
confirm('...') && doDelete()—— 短路逻辑掩盖了返回值语义，可读性差且不利于调试 -
prompt的输入内容务必做空值检查：const input = prompt('输入姓名'); if (input === null || input.trim() === '') return; - 所有三个函数都会阻塞 JS 主线程（包括页面渲染），在复杂页面中频繁使用会导致卡顿，尤其在旧版 Android WebView 中可能触发 ANR
现代项目里基本不该用它们，替代方案取决于具体场景
这些原生对话框样式不可定制、无法键盘导航、不支持国际化，且 prompt 已被主流浏览器标记为“deprecated in non-secure contexts”。真实项目中应替换为：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 简单提示：用轻量级 Toast 组件（如
toast.success('保存成功')），不打断用户操作流 - 确认操作：用模态框（Modal）+ 自定义按钮文案（例如“永久删除”“我已知晓风险”），并绑定
Escape键和点击遮罩层关闭 - 收集输入：用表单 +
focus()+Enter提交，比prompt更可控、可验证、可访问
唯一还可能保留原生弹窗的场景是调试时快速验证逻辑分支，或极简静态页（如个人简历页里的联系方式弹窗），但也要注意 prompt 在 HTTP 站点上大概率静默失败。
跨浏览器行为差异和兼容性陷阱
IE11 会把 confirm 的按钮文字本地化（如中文系统显示“确定/取消”），而 Chrome 始终显示英文（“OK/Cancel”），但返回值仍是标准布尔值，不影响逻辑。真正麻烦的是移动端：
- iOS Safari 中，
prompt的软键盘唤起有延迟，且输入框光标可能不自动聚焦 - 部分安卓定制浏览器（如华为浏览器）会拦截连续多次
alert，只显示第一个 - Electron 应用默认禁用这些函数，需在
webPreferences中显式开启javascript: true并确保未设置disableDialogs: true
如果你正在维护一个老系统且必须用它们，请至少封装一层：统一处理 null/undefined 返回、添加超时 fallback、记录调用位置便于后续替换——毕竟它们的 API 表面简单，实际坑全藏在边缘行为里。
