应优先用实现语义化模态弹窗，兼容性不足时降级为手写div方案；alert/confirm/prompt仅适用于调试或极简场景，因其阻塞脚本、不可定制、移动端支持差且无障碍缺陷明显。
alert、confirm、prompt 能快速实现基础弹窗，但它们阻塞脚本、无法定制样式、移动端支持差；真要“在 HTML 编辑器里写弹窗”，你得明确目标：是调试用的临时提示，还是交付给用户的可访问交互组件？答案不同，路径完全不同。
用 alert/confirm/prompt 写原生提示框，只适合调试或极简场景
这三者是浏览器内置函数，不依赖 HTML 结构，调用即显，但副作用明显：
-
alert("保存成功")会暂停所有 JS 执行，用户不点确定，后续逻辑卡死 -
confirm()返回true/false，但按钮文字不可改，“确定/取消”硬编码，无法本地化 -
prompt()输入框无校验、无占位符、移动端软键盘可能遮挡内容，返回值可能是null或空字符串，必须手动判断 - 它们在 iOS Safari 和部分安卓 WebView 中会被系统拦截或样式异常，且完全不支持键盘导航（Tab 键无法进入）
用 <dialog></dialog> 实现语义化模态弹窗，现代浏览器首选
<dialog></dialog> 是 HTML5 原生模态元素，无需额外 DOM 操作，但必须用 JS 触发，且兼容性有硬门槛：
- 必须用
dialog.showModal()显示，dialog.open = true无效；关闭必须调用dialog.close()，不能只设open = false - 默认样式差异大：Chrome 给
<dialog></dialog>加了16px外边距，Safari 可能圆角丢失，务必重置：dialog { margin: 0; padding: 1em; border: none; border-radius: 6px; } - 遮罩层（
dialog::backdrop）点击默认关闭，但该伪元素在旧版安卓 WebView 中不支持，需备选方案（如外层加<div class="backdrop">） <li>运行时检测比 <code>@supports可靠：if ('showModal' in HTMLDialogElement.prototype)，否则降级需手动管理焦点、Esc 键、aria-modal和inert - 遮罩层必须设
position: fixed和足够高的z-index（建议 ≥ 1000），否则可能被第三方 UI 库覆盖 - 弹窗居中别用
top: 50%; left: 50%，优先用transform: translate(-50%, -50%)，避免因父容器transform导致定位偏移 - 模态弹窗打开时，记得给
加overflow: hidden防止滚动穿透；关闭后要恢复，否则页面会卡住 - 用户输入内容直接拼进
innerHTML有 XSS 风险，消息文本一律用textContent设置 - 必须监听
Escape键并调用关闭逻辑，否则键盘用户无法退出 - 只能在真实点击事件回调中调用，
setTimeout、fetch.then、Promise回调里调用会静默失败，控制台报Blocked opening 'xxx' in a new window because the request was made without user activation. - 第二个参数（窗口名）必须唯一，重复使用同一名称会导致复用旧窗口而非新开
- 第三个参数（特性字符串）漏掉
scrollbars=yes，内容溢出时无法滚动；漏掉resizable=yes，用户无法调整大小 - 移动端基本无视该 API，Safari 直接禁用，Chrome 强制在新标签页打开
手写 div + CSS + JS 弹窗，控制力最强但细节最多
动态创建 <div class="overlay"><div class="dialog">...</div></div> 是最通用方案，但容易踩坑：
别碰 window.open() 做“弹窗”，它早不是你想的那样
现代浏览器严格限制非用户触发的 window.open()，实际已退化为标签页跳转：
真正难的不是“怎么让框弹出来”，而是“怎么让它对键盘用户友好、对屏幕阅读器可读、对旧设备可降级、对用户操作不打断”。<dialog></dialog> 看似简单，但 showModal() 不可用时的 fallback 焦点管理，才是多数人没写对的地方。
