popover仅适用于轻量浮层，不能替代dialog；它不支持焦点锁定、esc关闭或可访问性语义，而dialog是唯一原生支持模态交互与wcag标准的html元素。
popover属性适合“轻量浮层”，不是用来替代dialog的
如果你正考虑用 popover 属性替代 <dialog></dialog> 实现登录弹窗、表单确认或关键操作拦截，那大概率会出问题。popover 的设计目标非常明确：只处理“非模态、瞬时、低干扰”的覆盖内容，比如字段说明、工具提示、指标详情浮层。它不接管焦点、不锁背景、不响应 Esc 键，也没有语义化的模态行为约束。
常见错误现象包括：用户点击 popover 外部没反应（因为默认不支持 light dismiss）、键盘焦点穿透到背后表单、屏幕阅读器无法识别其为可交互对话上下文。
-
popover必须配合popovertarget或 JavaScriptshowPopover()/hidePopover()触发，不能靠open属性控制 - 它自动进入浏览器 Top Layer，层级高于所有
z-index，但这也意味着它可能意外遮挡真正需要优先级的<dialog></dialog> - 在 Chrome 115+ 和 Safari TP 167+ 中可用，但 Safari 正式版稳定支持仍受限（截至 2026 年 9 月）
dialog标签是唯一原生支持模态语义与可访问性的HTML元素
当你需要用户必须响应、中断当前流程、或保障焦点/键盘/屏幕阅读器行为一致时，<dialog></dialog> 是目前 HTML 中唯一被 WCAG 和主流浏览器共同认可的方案。它的 showModal() 不只是显示，而是激活一整套模态契约：焦点锁定、Esc 关闭、inert 背景、aria-modal="true" 自动注入、关闭后焦点返回触发源。
使用场景很具体：超时续期警告、删除确认、多步表单中断提示、权限缺失引导——这些都不是“看看就走”的浮层，而是需要用户明确决策的界面节点。
- 调用
showModal()后，<dialog></dialog>会自动添加open属性并生成 backdrop 元素（不可通过 CSS 伪类选中） - 表单内设
method="dialog"可让提交按钮直接关闭 dialog 并设置returnValue，无需监听 submit 事件 - 若手动控制显隐（如用
show()），需自行管理焦点和键盘逻辑，否则可访问性会降级
两者混用时，层级和焦点冲突是真实存在的坑
别以为把 <dialog></dialog> 和 popover 放在同一页面就万事大吉。实测中，popover 容器可能渲染在 <dialog></dialog> 的 Top Layer 之上，导致关键模态框被遮挡——尤其在多步骤复杂表单中，用户点不到“延长会话”按钮，直接被登出，已填数据全丢。
这不是理论风险。Chrome Canary 115 演示过该问题，且至今未完全修复；Safari 对两者的 Top Layer 调度策略也不完全一致。
- 避免在
<dialog></dialog>内部嵌套popover，或反过来；它们不属于同一交互范式 - 如果必须共存，优先确保
<dialog></dialog>是最后 append 到 body 的顶层元素（DOM 顺序影响 Top Layer 渲染顺序） - 测试时务必用键盘 Tab + Esc + Screen Reader（如 VoiceOver）验证焦点流，不能只看视觉层级
兼容性差异比想象中更实际
别只盯着 CanIUse 上的绿色勾。Safari 15.4+ 才完整支持 showModal()，而 15.2–15.3 存在焦点锁定失效；popover 在 Safari 正式版中仍处于实验阶段，需开启 flag 才能启用。这意味着你写的 popover 在多数 iOS 用户设备上根本不会渲染。
相比之下，<dialog></dialog> 的 polyfill（如 @oddbird/dialog-polyfill）成熟稳定，能 fallback 到 position: fixed + inert + 焦点管理，而 popover 几乎没有可靠 polyfill。
- IE 和旧 Android WebView 完全不支持二者，但
<dialog></dialog>有可落地的降级路径，popover没有 - 服务端渲染（SSR）场景下，
popover的初始状态不可控（无open属性），而<dialog open></dialog>可服务端输出可见态 - 如果你的项目要上生产，现在用
popover做核心交互，等于主动放弃一部分真实用户
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
