<dialog> 默认隐藏且非模态，需调用 showModal() 而非 show() 才具备背景失焦、Esc 关闭等特性；须手动设置 dialog::backdrop 样式、管理焦点、监听 close 事件并解析 returnValue，Firefox 98 前需 polyfill。
dialog 元素默认不阻塞页面交互
直接写 <dialog></dialog> 并不会弹出模态框，它初始是隐藏的，且 open 属性必须显式设置才能显示。更关键的是，即使加了 open，它默认也不阻止背景点击或 Tab 键切换——这和用户预期的“确认/取消对话框”行为不符。
实操建议：
- 必须调用
showModal()而非show()，否则无法获得模态特性（如背景失焦、Esc 关闭、焦点捕获） - 不要手动加
open属性来“预显示”，showModal()会自动添加，重复设置可能干扰状态判断 -
dialog不自带遮罩层样式，需自行用dialog::backdrop设置背景色，否则视觉上无模态感
确认取消按钮需主动 close() 且监听 close 事件
dialog 的关闭逻辑完全由 JS 控制：点击“确认”或“取消”按钮后，必须显式调用 dialog.close()；而用户点遮罩、按 Esc 或点浏览器返回时，会触发 close 事件，但不会自动清除状态或执行业务逻辑。
常见错误现象：点了“确定”按钮，dialog 关了，但后续操作没执行——因为只写了 dialog.close()，没在 close 事件里处理结果。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 给“确认”按钮绑定点击事件，执行业务逻辑后调用
dialog.close('confirmed')（传字符串可区分关闭原因） - 给“取消”按钮绑定点击事件，直接调用
dialog.close('canceled') - 监听
dialog.addEventListener('close', () => { ... })，从dialog.returnValue读取传入值，再决定是否提交表单、刷新列表等
Firefox 对 dialog 支持需 polyfill 或降级处理
Firefox 直到 98+ 才原生支持 <dialog>，旧版本会直接忽略该标签，内容始终可见或布局错乱。不能假设所有用户环境都可用。
使用场景：面向企业内网系统（IE 已淘汰但 Firefox 旧版仍存）或需兼容性兜底的生产项目。
实操建议：
- 检测支持性：
if (!('showModal' in HTMLDialogElement.prototype))，不支持则动态加载@ungap/dialog-polyfill并调用dialogPolyfill.registerDialog(dialogEl) - 避免仅靠 CSS 隐藏未支持的
dialog（如dialog:not([open]) { display: none; }），polyfill 依赖真实 DOM 结构，提前隐藏可能导致初始化失败 - 服务端渲染时，若明确不支持，可 fallback 为
<div role="dialog">+ 手动管理 aria-modal / focus trap
focus 管理和键盘导航容易被忽略
模态框打开后，Tab 键应只在 dialog 内部循环，Esc 应关闭，Enter 应触发默认按钮——这些不是 dialog 自动提供的，需手动补全。
性能影响：不处理焦点会导致屏幕阅读器用户迷失，也违反 WCAG 2.1 标准。
实操建议：
- 调用
showModal()后，立即dialog.querySelector('button[data-default]')?.focus()，确保首次聚焦在合理位置 - 监听
keydown事件，捕获Escape并调用dialog.close()（虽然原生支持，但 polyfill 环境需手动） - 对 Enter 键做判断：若当前聚焦元素是按钮或输入框，且 dialog 处于 open 状态，则触发其 click 行为，避免穿透到背景
close 事件监听和 returnValue 解析——按钮点了，UI 关了，但业务流程卡在那，得翻控制台才意识到没接住回调。 
